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or target systems. His organization has 
been trying to emulate a “reasonable sub¬ 
set” of the Win32 API to demonstrate 
that emulation is possible under UNIX, 
and they have been able to implement 
most low-level constructs of Win32. 

The problem they originally set out to 
solve was: Given a console application for 
Win32 written in Visual C++ 5.0 with 
use of the Standard Template Libraries 
(STL) and running under Windows 95 or 
NT, compile and execute the same code 
on UNIX, with gcc 2.8.1 and STL, for 
Solaris 2.6 (sparc/x86) or Linux 2.0 
(x86). 

By “a reasonable subset,” Paas means 
implementation of a couple key areas. 
The first is support for NT multithread¬ 
ing (i.e., the ability to create, destroy, sus¬ 
pend, and resume preemptive threads) 
and for most synchronization and 
thread-local storage (TLS) functions. To 
demonstrate memory management abili¬ 
ties, they wanted to be able to allocate, 
commit, and protect virtual memory on 
the page level, as well as support memory 
mapping I/O and files. They wanted to 
provide user level page fault handling 
with structured exception handling 
(SEH) to emulate NT SEH. Finally (and 
ambitiously), they wanted to provide use 
of the Winsock API for TCP/IP under the 
emulator. 

Paas then went into the implementation 
details of nt2unix, comparing code to 
accomplish common tasks such as creat¬ 
ing a thread in NT versus POSIX versus 
Solaris. Creating a thread is in itself very 
simple, but the differences between oper¬ 
ating systems meant they had to ignore 
LPSEC attributes like Windows 95 does. 

One major problem with thread synchro¬ 
nization is that suspending and resuming 
threads is not possible under the POSIX 
thread API. Additionally, some Win32 
thread concepts are hard to implement 
efficiently within POSIX. The NT kernel 
usually handles this, but in UNIX it must 
be done manually, which implies some 
performance hits. 


Memory management turned out to be 
fairly easy. Structured exception handling 
wasn’t as easy and couldn’t be supported 
directly, since supporting the keywords 
try and except would require a change in 
the compiler. They decided to implement 
SetUnhandledExceptionFilterO, which 
creates a global signal handler. Mapping 
NT exception codes to UNIX signals, 
where there isn’t always a good match, 
made this difficult. 

To enable TCP/IP networking using 
Winsock, they decided to restrict 
Winsock 2.0 to the BSD Sockets API. The 
bulk of the task was translating data 
types, definitions, and error codes. Paas 
notes that the pitfalls in this are that 
some types are hard to map, like fd_set: 
Winsock’s select() function is most defi¬ 
nitely not BSD’s selectO. 

To test their solutions, they emulated a 
15,000-line native Win32 Visual C++ 
code module, SVMlib. This shared virtu¬ 
al-memory library is all-software, user- 
level, and page-based. They ran this with 
nt2unix with no source code changes. 
Initial time comparisons show satisfacto¬ 
ry behavior, the major reason for slightly 
slower performance than on a Win32 
platform being that UNIX signal han¬ 
dling is significantly more expensive than 
Win32 event handling. 

Paas’s team concluded that Win32 API 
emulation under UNIX is very possible, 
and that if the emulator is application- 
driven, it can be implemented within 
finite time (three man-months). Paas says 
“nt2unix is a reasonable first step to 
develop portable low level applications.” 
In the future they would like to imple¬ 
ment a more complete set of Win32 base 
services, allowing more applications to be 
run under UNIX (NT services could be 
run as UNIX daemons, for example). 

nt2unix: <http://www.lfbs.rwth-aachen.de/ 
-karsten/projects/nt2unix> 

SVMlib: <http://www.lfbs.fwth-aachen.de/ 
'-karsten/projects/SVMlib> 


NT-SwiFT: Software Implemented Fault 
Tolerance on Windows NT 

Yennun Huang, P. Emerald Chung, 
and Chandra Kintala, Bell Labs, 
Lucent Technologies; Chung-Yih Wang 
and De-Ron Liang, Institute of 
Information Science, Academia 
Sinica 

Yennun Huang presented NT-SwiFT, a | 
group of software components imple¬ 
mented to provide fault tolerance on ' 
Windows NT. These were originally 
developed for UNIX and have been port¬ 
ed to NT with new features added. 

The problem is to make distributed 
applications highly available and fault 
tolerant. Huang outlined three possible 
solutions: (1) transaction processing as in 
Microsoft Transaction Server; (2) active^ 
replication / virtual synchrony as in ISIS, 
HORUS, and Ensemble; (3)checkpoint-' 
ing and rollback recovery, which is the 
approach SwiFT takes. ' 

SwiFT supports three types of process ' 
replication for rollback recovery: cold, ^ 
warm, and hot. Cold is fail-over with or, 
without checkpointing. Warm is primary 
backup with state transfer. Hot uses an | 
active process group with no shared i 
memory. Regardless, the overall philoso¬ 
phy was to keep the error recovery mecft- 
anism transparent from client programs; 
and to enhance fault-tolerant server pro¬ 
grams with fault tolerant APIs. 

After an extremely detailed catalog of the 
many components of SwiFT and what | 
they can be used for, Huang provided 
some general information about SwiFT 
in general. UNIX SwiFT has been used in 
Bell Labs for more than five years and is 
used in more than 20 products and ser- ^ 
vices. Its technologies have been licensed 
to a few companies. A few projects in 
Lucent are trying NT-SwiFT. 

SwiFT was originally ported to NT on 
UWIN but was re-implemented with 
many new features. UWIN 1.33 works, 
but not quite. By writing new driver 
code, they obtain less software dependen- 
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cy, a new GUI, new features, and a much 
needed understanding of NT internals. 

The basic procedure is that when a 
process is initially created, important sys¬ 
tem calls and events are intercepted and 
recorded. This is a sneaky and very trans¬ 
parent solution: a whole process space 
can be set up (using NT calls 
VirtualQueryO and Virtual ProtectO). 
Handles can be restored with library 
injection techniques and modification of 
import address tables. For client-server 
applications, they use an intermediate 
NDIS driver, which allows them to set up 
a dispatcher and server node with the 
same IP address. The dispatcher node can 
be failed over. 

Huang gave a very interesting demo of 
the checkpoint and process-space recov¬ 
ery features using the beloved 
minesweeper application. This was both 
humorous and very effective: after plac¬ 
ing a few mines, he took a checkpoint, 
placed a few more, and, naturally, “blew 
up” when he clicked a bad square. Then 
he restored from the last checkpoint, 
which, he explained, actually launched 
the process, restored its process space, 
and replayed a sequence of events. This 
allowed him to “try again” and check¬ 
point again when he clicked a few good 
squares. While trivial, it clearly demon¬ 
strated the possibilities of the system. 

Huang expressed a few opinions about 
NT, namely that it has too many APIs 
and libraries (really?), but that it is very 
powerful and that “everything is possible 
in NT.” It has many useful facilities, and 
although the OS can be an esoteric maze 
at times, a good point is that if you have 
a problem, someone somewhere has 
probably written some code to solve it, 
and it*s fairly easy to find free code sam¬ 
ples. 

Huang stated a few future goals for 
SwiFT. They’d like to bring it to Windows 
98. They are planning to add a few com¬ 
ponents (CosMic, addrejuv), more NT 
system calls trapping, and more dispatch¬ 
ing algorithms for ONE-IP. They’d also 


like to see SwiFT for distributed objects 
(CORBA, DCOM, and JAVA). Finally, 
they’d like to integrate SwiFT with other 
tools (MSCS) and NTS. 

In the Q/A session, someone wanted to 
know about availability. The answer 
wasn’t very clear, but it’s under license 
and at this point is not very available 
(still in progress). People had many ques¬ 
tions about the Winmine demo. Huang 
made it clear that GDI objects like brush¬ 
es can not be captured: there’s no way to 
understand them outside of a process 
space. For the demo, they use window 
handles only. Someone wanted to know if 
it was possible to save on one machine 
and recover on another, as this would be 
a very useful feature for load balancing. 
The answer is yes, but it has to be exactly 
the same type machine with the same 
configuration because of memory inter¬ 
nals. Someone wanted to know if this 
would be able to run more than one 
process per server (for example, could 
you run thousands of SwiFT-backed 
objects on a server?), and could SwiFT 
run for days without crashing? The 
answer: “We’re working on it.” 

Session: Threads 

Summary by Kevin Chipalowsky 

A Thread Performance Comparison: 
Windows NT and Solaris on a 
Symmetric Multiprocessor 

Fabian Zabatta and Kevin Ying, 
Brooklyn College and CUNY Graduate 
School 

Kevin Ying began by observing that the 
cost of multiprocessing equipment has 
dropped drastically over the past few 
years. A dual-processor IBM SP2 sold for 
$130,000 in 1995, and a more powerful 
system built with Pentium II processors 
costs around $13,000 today. With this 
much computing power readily available, 
mainstream operating systems need to 
support multithreading. 

Both Windows NT and Solaris support 
kernel-level and user-level subprocess 


objects of execution. Windows NT calls 
its kernel objects “threads” and its user 
objects “fibers.” The application pro¬ 
grammer has complete control over the 
scheduling of fibers. Solaris calls its ker¬ 
nel objects “Light Weight Processes” 
(LWP) and its user objects “threads.” 
Unlike NT, Solaris provides a user level 
library to schedule threads to run on 
LWPs. 

In their research, Zabatta and Ying per¬ 
formed seven experiments to test the rel¬ 
ative multiprocessing performance of the 
two operating systems. They tested kernel 
execution objects in Windows NT only, 
but tested bound, unbound, and restrict¬ 
ed concurrency level threading in Solaris. 
A bound thread in Solaris’s user level 
library is a single thread that is always 
scheduled on a single LWP. An unbound 
thread is dynamically scheduled on a 
dynamically chosen number of LWPs, but 
the concurrency level can be restricted to 
a fixed number. In their concurrency 
restricted case, Zabatta and Ying limited 
the library to four LWPs (CL=4), because 
their experimental system had four 
processors. 

Ying explained that neither operating sys¬ 
tem documented a limit on the number 
of kernel execution objects it could cre¬ 
ate. Their first experiment was to discov¬ 
er this limit. They found the Windows 
NT limit to be around 9800, and the 
Solaris limit to be around 2200. The sec¬ 
ond experiment tested normal thread 
creation speed. They wrote a simple pro¬ 
gram to create threads in a loop. 
Performance of NT and Solaris bound 
threads were very comparable. However, 
unbound Solaris threads could be created 
much faster. They also tested thread cre¬ 
ation speed while the system was under a 
heavy load. In this situation, the creation 
of all types of Solaris threads was drasti¬ 
cally faster than creation of Windows NT 
threads. Ying informed us that this could 
be expected, because NT gives a higher 
priority to threads that have been run¬ 
ning for a long time, while Solaris gives a 
higher priority to newly created threads. 
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In the fourth experiment, performance 
was measured for an application requir¬ 
ing no synchronization. They found no 
major differences in running times by 
any of the threading models. This led 
them to conclude that the Solaris thread¬ 
ing library does not significantly affect 
performance. Next, they tested perfor¬ 
mance in an application making heavy 
use of synchronization. Windows NT has 
two different types of synchronization 
objects. A critical section has local scope, 
and a mutex has global scope. Solaris 
only has critical sections, but it has a cre¬ 
ation flag, which determines scope. 
Zabatta and Ying found that Windows 
NT critical sections drastically outper¬ 
form local Solaris ones. However, global 
synchronization objects in Solaris out¬ 
perform the global ones in NT. In the 
sixth experiment, they tested perfor¬ 
mance using the classic symmetric travel¬ 
ing salesman problem. The significant 
result was an almost linear speedup with 
parallelism. All threading models had 
very similar performance. The final 
experiment attempted to mimic real 
world applications with CPU bursts. 

They tested each threading model with 
drastic CPU bursts and found the 
restricted concurrency Solaris threads 
slightly outperform the others. Ying 
attributed this to Solaris’ two-tier system. 

Ying concluded by reiterating the scala¬ 
bility of each model, the flexibility of 
Solaris’s design, and the performance 
advantages of NT’s critical sections. 

A System for Structured High- 
Performance Multithreaded 
Programming in Windows NT 

John Thornley, K. Mani Chandy, and 
Hiroshi Ishii, California Institute of 
Technology 

John Thornley opened by reminding us 
of a time-honored idea: multithread pro¬ 
grams on multiprocessor computers to 
make them run faster. However, the idea 
of multithreaded programming has still 
had very little impact on mainstream 


computing. Thornley asks and tries to 
explain why this is so. 

In his explanation, there are three types 
of obstacles to the widespread adoption 
of multithreaded systems: the availability 
of symmetric multiprocessing (SMP) 
computers, the lack of programming sys¬ 
tems, and the difficulty of software devel¬ 
opment. Until recently, SMP technology 
was been very expensive and rare. 
Software tools were always limited. Most 
were primitive and the product of acade¬ 
mic research. They have always been 
unreliable, nonportable, and difficult to 
program. Things are changing. SMP 
computers are finally becoming cheap 
enough for their use to spread beyond 
expensive research labs. Commodity 
operating systems, notably Windows NT, 
support threaded software. Multithreaded 
programming, however, remains difficult. 
This is the focus of the research Thornley 
presented. 

Why is programming so tough? Thornley 
argues that the problem is a lack of struc¬ 
ture. Current tools are designed for sys¬ 
tems programming, which is small subset 
of all programming that could benefit 
from SMP computers. Current synchro¬ 
nization operations are also very error- 
prone because of their nondeterminism. 
These tools are at the level of “goto” 
sequential programming. We need struc¬ 
tured design techniques, modeled after 
tried-and-true sequential techniques. We 
need direct control of threads and syn¬ 
chronization. We need determinacy 
unless explicit nondeterminacy is 
required. And we need performance that 
is portable across different hardware and 
with different background loads. 

The authors developed Sthreads, a new 
package of tools to deliver this function¬ 
ality. The programming model is “multi¬ 
threaded program = sequential program 
+ pragmas + library calls.” They claim 
that if a programmer follows the rules of 
the model, multithreaded execution is 
equivalent to sequential execution. This 
determinacy has many important conse¬ 


quences simplifying software develop¬ 
ment. For example, a program designed 
for multithreading can be run sequential¬ 
ly for debugging. 

Sthreads is not a parallelizing compiler. 
Their pragmas are not hints; they are 
specific directives. They are used around 
blocks and “for” loops and indicate the 
section of code that should be explicitly 
multithreaded. The Sthreads library pro¬ 
vides counters to guarantee correct order 
of execution, but also provides access to 
traditional locks for nondeterministic 
programming. 

Thornley presented a trivial code exam¬ 
ple that multiplies matrices. A pragma 
indicating that it should be multithread¬ 
ed precedes the outer “for” loop. His sec¬ 
ond example was a little more complicat¬ 
ed. It sums up arrays of floating point 
numbers. Since floating point arithmetic 
is not associative, the order of execution 
matters. To ensure equivalency to sequen¬ 
tial execution, Thornley’s example uses a 
counter. It guarantees sequential ordering 
and mutual exclusion in a section of 
code. The use of Sthreads for this exam¬ 
ple is far simpler than using the Win32 
thread API. 

The researchers theorize that this is all 
you need to make programs run fast. 
They think that hardware and operating 
system software are ready for multi¬ 
threading of commodity software. 
Thornley made the very strong statement 
that if multithreaded programming is not 
this simple, then it will never become j 
mainstream. He ended with the following 
testimonial. They took a difficult aircraft 
route optimization problem and imple¬ 
mented a solution using the Sthreads 
tools. In the end, their solution running | 
on an SMP system with four Intel proces¬ 
sors outperformed a Cray supercomputer 
solving the same problem using an 
implementation designed with traditional 
programming techniques. 
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A Transparent Checkpoint Facility On NT 

Johny Srouji, Paul Schuster, Maury 
Bach, and Yulik Kuzmin, Intel 
Corporation 

Paul Schuster and Johny Srouji presented 
their research and resulting checkpoint 
tool. Checkpointing is the act of captur¬ 
ing the complete state of a running 
process. Once captured, it can later be 
used to resume the process either on the 
same machine or be migrated to another. 

In the past, many checkpointing tools 
have been built for UNIX systems, but 
this group began the development of 
their tool not knowing of any others for 
Windows NT. Given NT’s increased usage 
over the past few years, they believed that 
such a tool was definitely needed. 

The motivation for checkpointing is 
strong. It is a good way to prevent the 
loss of data that is due to the failure of a 
long-running process. It can also be used 
for debugging, to determine why that 
long-running process failed and resulted 
in data loss. Most significantly, check¬ 
pointing can be used to migrate a process 
from one machine to another in a dis¬ 
tributed environment, possibly to 
improve resource utilization. 

There were a number of design goals in 
the project. Foremost, it needed to be 
transparent to the running application, 
so no source code changes could be 
required. Obviously, it needed to be cor¬ 
rect, but with a minimal performance 
impact. It also had to be application- 
independent and support multithreaded 
processes. The designers tried to make 
their implementation as portable as pos¬ 
sible, although they discussed only the 
NT implementation. 

For a checkpoint facility to be correct, it 
needs to capture the complete state of a 
process. Schuster and Srouji illustrated a 
layering of process state components. 

User objects, such as memory and thread 
contexts, were on the bottom. System 
state objects were above those, and GUI 
and external state objects were at the very 


top. Moving up the layers, the complexity 
of capturing state increased. Schuster and 
Srouji said they did not even attempt to 
capture state for the highest layers. Their 
tool is limited to console applications. 

It has both a user interface and a devel¬ 
oper interface. The user runs an applica¬ 
tion using an alternate loader, which con¬ 
figures the app to run with automatic 
checkpointing. Alternatively, the applica¬ 
tion developer can explicidy control 
when checkpointing occurs by using a 
provided API. 

Schuster and Srouji described the archi¬ 
tecture of the checkpoint tool. Their 
checkpoint DLL is loaded into the user 
memory space by the loader. Its DllMain 
is called first, which rewrites the Import 
Address Table (lAT). In doing so, it forces 
all Win32 API calls to be redirected to 
checkpoint DLL functions. 

When it is time to perform a checkpoint, 
the tool has access to all needed states. 
User state is in user memory, and since 
the tool is implemented as a DLL run¬ 
ning in user memory space, it can direct¬ 
ly access it. State associated with system 
calls is stored in system memory. The 
checkpoint DLL does not have access to 
that memory, but it can infer the system’s 
internal state because it had a chance to 
see all system calls. 

To resume a process, the checkpoint tool 
loads the application suspended. It 
rebuilds the state in the reverse order it 
captured it. Finally, it releases the applica¬ 
tion threads and they runs as if they were 
never stopped. 

As implemented, Schuster and Srouji’s 
work has a few limitations. Most relate to 
external state, which they cannot control. 
If a process creates any temporary files, 
they must still exist in their checkpointed 
states during resume. Any applications 
that bypass the lAT (by using 
GetProcAddress, for example) might not 
resume correctly. And their tool does not 
even attempt to deal with simultaneously 
checkpointing multiple processes that 


interact. In the future, they plan to con¬ 
tinue their research with more optimiza¬ 
tions and more comprehensive API sup¬ 
port. They hope to improve performance 
with incremental memory dumps. 
Eventually, they hope to use their check¬ 
pointing tool for process migration. 

Poster and Demo Session 

Summary by Michael Panitz 

The Poster and Demo session was a pop¬ 
ular, well-attended event featuring many 
research projects in a wide range of areas, 
from dynamic optimization to process 
migration to NT-UNIX connectivity. The 
session began with the session chair, John 
Bennett, inviting project presenters to 
give a one-minute summary of their pro¬ 
jects. After the summaries, the audience 
was free to roam about, conversing both 
with the project presenters and among 
themselves. 

Many of the projects focused on net¬ 
work-related advances. A Bell Labs/ 
Microsoft team collaborated on a project 
that exploited COM’s custom mar¬ 
shalling ability to run DCOM on RMTP, 
a multicast network protocol. A group 
from Harvard presented a cluster-based 
Web server in which page requests are 
preferentially forwarded to specific 
nodes, thus significantly increasing per¬ 
formance by decreasing the total number 
of pages each node is expected to serve. 
The Milan/Chime project demonstrated a 
distributed shared memory system which 
was used to support distributed preemp¬ 
tive scheduling (and task migration). 
Martin Schulz, from the SMiLE group at 
TU-Munich, presented a system for 
building a shared memory system, which 
supports transparent, cluster-wide mem¬ 
ory by exploiting SCI’s hardware DSM 
support. Finally, the Brazos parallel pro¬ 
gramming environment was presented, 
which facilitates parallel programming by 
offering features such as being able to run 
a Brazos program on uniprocessor, SMP, 
or clustered computers without recompi¬ 
lation. 
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Two posters dealt with connecting NT to 
other systems. Motohiro Kanda presented 
a mainframe file system browser, which 
allows one to access to file system of a 
Hitachi 7700 mainframe from Windows 
NT. Network Appliance demonstrated a 
specialized, multiprotocol file server that 
utilizes the SecureShare technology that 
was described in the Mixing UNIX and 
NT technical session. The main feature of 
the NetApp file server was that it sup¬ 
ports both UNIX and NT file sharing. It 
allows NT clients to access UNIX files 
and vice versa, in addition to NT to NT/ 
UNIX to UNIX access, all without client 
modification. 

In a class by itself was SWiFT (not to be 
confused with the checkpointing project 
NT-Swift), a toolkit to build adaptive sys¬ 
tems. The system is based on feedback 
control theory, and seeks to apply hard¬ 
ware control theory to software prob¬ 
lems. In doing so, it facilitates the use of 
modular control components, explicitly 
specified performance parameters, and 
from there, the automatic, dynamic 
reconfiguration of software modules for 
good performance despite a changing 
environment. 

KEYNOTE ADDRESS 

Buying Computing and Storage 
by the Slice 

Gary Campbell, Tandem Computers 
Inc. 

Summary by Dan Mihai Dumitriu 

Gary Campbell gave a compelling argu¬ 
ment for cluster technology as a more 
scalable and cost-effective replacement 
for SMPs, MPPs, and Supercomputers. 

He argues that in today s computing 
world, SAN (System Area Network) tech¬ 
nology has matured to the point where it 
is a feasible interconnect for clusters. 

Key technologies that must exist in order 
for “computing by the slice” to succeed 
are: x86 SMP systems, which are very 
inexpensive today; balanced PCI; SAN 
interconnects such as VI (Virtual 


Interface)-based solutions; and parallel 
programming standards. 

Alternative technologies to clustering are 
SMPs, which do not scale indefinitely and 
do not have the best price-performance 
curve, and CC-nUMA (Cache Coherent 
Non-Uniform Memory Access). When 
applications start to get broken up on a 
nUMA machine, it starts to look more 
and more like a cluster. In addition, both 
of these technologies have single points 
of failure, whereas clusters are architec¬ 
turally ready for fault-tolerant features. 

The hardware necessary for computing 
by the slice is available, but the software 
side still needs work. “Legacy” cluster sys¬ 
tems - such as Tandem NSK, IBM SP2, 
and Digital UNIX - are too difficult to 
replicate. More recent products such as 
Microsoft’s cluster service, affectionately 
(?) called “Wolf Pair,” do not scale well. 
Much work is needed in the software and 
the distributed APIs. 

Some case studies of “computing by the 
slice”: The IBM DB2 database running on 
2 P6-200MHZ machines interconnected 
with ServerNet gets 91% scaling. The 
Inktomi Web search engine, which is a 
Berkeley NOW derivative, is built out of 
150 dual-processor UltraSparc II 
machines connected with Myrinet. This 
highly parallel search engine can index 
110 million documents and is highly eco¬ 
nomical. The Sandia Allegra Model was 
originally built on Cray, later on Paragon. 
Now it is running on DEC Alpha s inter¬ 
connected with Myrinet. 

The conclusion was that computing by 
the slice offers superior price/perfor¬ 
mance, is architecturally ready, has lower 
time and cost to market, and is even 
gaining ground in traditionally super¬ 
computer applications like sparse matrix 
computations, and also in commercial 
parallel databases. The architecture is 
primarily limited by the software. In 
the future look for COM+, Java EJB, 
and other perhaps more dramatic 
developments. 


KEYNOTE ADDRESS 
Here Comes nUMA: 

The Revolution in Computer Architecture 
and its OS Implications 

Forrest Basket, Silicon Graphics Inc. 

Summary by Dan Mihai Dumitriu 

Forrest Basket presented an argument for 
CC-nUMA (Cache Coherent Non- 
Uniform Memory Access). He asserted 
that the nUMA architecture is inevitable 
in today s computing world, and he pre¬ 
sented a successful implementation of the 
hardware and software. 

Basket pointed out some problems that 
arise in modern systems: faster buses 
must be shorter and run hotter, and 
faster CPUs run hotter and so need more 
volume for cooling. Using point-to point 
wires rather than buses allows you to run 
them faster and cooler. 

The SGI Origin 2000 is a successful 
implementation of CC-nUMA. It has an 
integrated nUMA crossbar and a fat- 
hypercube interconnect. It has a coher¬ 
ence and locality protocol, 64-bit PCI, 
and some fault-tolerant features. Each 
node in the Origin 2000 has two MIPS 
RIOOOO CPUs. 

The operating system is Irix 6.5. The 
computational and 10 semantics of the 
system are the same as for an SMP. For a 
small nUMA system an SMP OS will 
work, as will SMP applications. Some dis¬ 
advantages are additional levels in mem¬ 
ory and 10 hierarchy. Even though the 
system has a high-performance intercon¬ 
nect, latency in memory access is an 
issue, as is the contention for resources 
between nodes. 

According to Basket, in order to optimize 
performance of parallel applications, we 
want to be able to specify the topology of 
the system as well as affinities for devices, 
and to be able to do this without modify¬ 
ing binaries. Other issues that arise are 
page migration between nodes and mem¬ 
ory placement policies. Modifications to 
the OS kernel are necessary to support 
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being able to specify the initial placement 
of applications consistent with the user- 
specified system topology, replication of 
the kernel at boot time, a reverse page 
table, and a page locking scheme. System 
management is also an issue with 
nUMAs. The ability to partition systems 
so we can perform administrative shut¬ 
down of parts of the system is desirable, 
as is a sophisticated batch system that 
would enable users to see consistent run¬ 
ning times. 

SMP and DSM (Distributed Shared 
Memory) (cc-nUMA is a variant of 
DSM) are displacing vector supercom¬ 
puters and MPPs. 

Session: Mixing UNIX and NT 

Summary by Michael Panitz 

Merging NT and UNIX Filesystem 
Permissions 

Dave Hitz, Bridget Allison, Andrea 
Borr, Rob Hawley, and Mark 
Muhlestein, Network Appliance 

Dave Hitz presented a fast and witty 
overview of the WAFL file system, which 
enables network-based file sharing with 
both UNIX and NT clients. Network 
Appliance has created a specialized file¬ 
sharing device that uses WAFL to ease file 
sharing in a mixed NT/UNIX environ¬ 
ment. The three design goals of WAFL 
are: to make WinNT/95 users happy by 
providing a security model that mimics 
NTFS; to keep UNIX users happy by pro¬ 
viding a security model that mimics NFS; 
and to allow Windows and UNIX users to 
share files with each other. 

Difficulties arise because UNIX (and its 
Network File System, NFS) and NT (and 
its Common Internet File System, CIFS) 
are fundamentally different, both in secu¬ 
rity models and in such aspects as case 
sensitivity (NTFS is case-insensitive, NFS 
is case-sensitive). NFS uses divides per¬ 
missions into (user, group, world), while 
CIFS uses Access Control Lists (ACLs). 
CIFS uses a connection-based authentica¬ 
tion scheme, while NFS is stateless. WAFL 


was primarily designed to bridge these 
two filesystems in the most secure man¬ 
ner possible, while secondarily providing 
as intuitive an interaction as possible. 

In addition to moderating access to files 
based on permissions, a filesystem is 
expected to display permissions, to allow 
them to modify these permissions when 
appropriate, and to be able to specify the 
default permissions to assign to a newly 
created file. WAFL uses both permission 
mapping and user mapping to accom¬ 
plish these goals. When a UNIX client 
accesses an NT file, access is determined 
by UNIX-style permissions that are gen¬ 
erated from the ACL via a process called 
“permission mapping.” These “faked-up” 
permissions are guaranteed to be at least 
as restrictive as the NT ACL. When an 
NT client requests access to a UNIX file, 
access is determined by mapping the NT 
user to a UNIX account, via a process 
called “user mapping.” The presentation 
argued that this was an effective, direct 
way to allow access in a secure, reason¬ 
ably intuitive manner. 

The presentation finished by touching on 
some of the issues surrounding WAFL, 
such as how to store NT ACLs, and on 
the administrative protocols used by NT. 

Pluggable Authentication Modules 
for Windows NT 

Naomaru Itoi and Peter Honeyman, 
University of Michigan 

Naomaru Itoi began the presentation 
with an anecdote about the motivation 
for creating a Pluggable Authentication 
Module (PAM) on NT. At the University 
of Michigan there existed authentication 
modules for both Kerberos and NetWare. 
This was great, but the authors wanted a 
module that provided authentication for 
both Kerberos and NetWare together; the 
only way to accomplish this was to create 
a third module. To create this under NT 
would have been difficult and time-con¬ 
suming. They wanted an authentication 
system would allow the user to log on 
once, yet use many services (“single sign- 


on”), a system that would be easy to 
administer, and a system that would be 
relatively easy to develop new authentica¬ 
tion modules for. What was wanted was a 
dynamic security system for NT, much 
like the PAM system that provides 
dynamic security for Linux and Solaris. 

After explaining why such a system 
would be useful, the speaker gave an 
overview of PAM, which is a de facto 
standard for administration, being part of 
Linux, Solaris, and the Common Desktop 
Environment (CDE), and also being stan¬ 
dardized by the IETF. PAM allows for 
security (re) configuration via a simple 
text file, which allows the administrator 
to specify such things as which services 
(Kerberos, NetWare, etc.) are required 
for, say, a logon attempt, or ftp session; 
which are optional; which services should 
be logged on to using the login password 
the user provides; which should be 
logged in to using a password stored in a 
password file, etc. PAM also provides a 
high-level API for authentication, so that 
different services can be wrapped and 
then configured without a recompilation. 

Itoi outlined a plan of attack by next 
explaining GINA, the administrator- 
replaceable “Graphical Identification and 
Authentication” user authentication com¬ 
ponent. GINA enables the administrator 
to replace the default user authentication 
module with another, but still suffers 
from the problem of having to write one 
module for the Kerberos service, one for 
the NetWare service, and a third for 
Kerberos and NetWare. Further, each 
module would have to be configured in 
its own way, thus making administration 
of any significant number of NT 
machines nearly impossible. Last, custom 
GINA modules require special debugging 
tools and the use of difficult techniques, 
since GINA is run before anyone logs in. 
The plan was to build a custom GINA 
that implemented a subset of PAM, so 
that NT could be used, administered, and 
developed for as easily as the UNIX PAM 
systems. 
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The design and implementation of PAM, 
named NI_PAM, was presented, includ¬ 
ing the API supported by NI_PAM; a dia¬ 
gram that showed which DLLs replaced 
the GINA.dll and their interaction was 
explained. 

Itoi reported that much of PAM has been 
successfully implemented, though more 
features need to be implemented, and 
more testing needs to be done, before a 
large-scale rollout can take place. The 
presentation concluded with some 
thoughts on alternate means of imple¬ 
menting PAM on NT, and possible future 
directions of the work, such as use of 
smartcards and screen saver locks. 

Montage - An ActiveX Container for 
Dynamic Interfaces 

Gordon Woodhull and Steven C. 

North, AT&T Laboratories - Research 

Montage grew out of an effort to create a 
Windows-friendly port of an abstract 
graph/network editor from UNIX. The 
Windows graph editor would integrate 
with Windows applications using ActiveX 
(also known as OLE - Object Linking and 
Embedding), a runtime, object-oriented 
technology. The edges and nodes of the 
graph would be embedded objects, and 
the application itself would be an embed¬ 
dable ActiveX container, which sounded 
easy enough. 

Unlike previously available containers. 
Montage separates both the layout and 
control of the contained objects and the 
interface used to control them from the 
container. Thus, Montage is actually an 
externally controllable object container 
that is being used to create a graph appli¬ 
cation, Dynagraph. Montage is itself an 
embeddable, customizable ActiveX 
object, and allows dynamic changes to 
the layout of contained objects. Thus, 
Montage could be used to display the 
current state of a computer network, 
unlike something like dotty, which is 
used to generate static graphs. All policy 
decisions (i.e., which objects should be 
placed where, what size should they be. 


etc.) are implemented objects indepen¬ 
dent of the Montage objects, thus allow¬ 
ing one to change the style of layout 
without recompiling Montage (unlike an 
VB MFC application). 

Montage exploits the OCX96 technology 
of “transparent controls” to provide for 
different modes of interaction with the 
objects. This allows Montage to provide a 
“Viewing Mode,” in which the user can 
view but not change the graph, and an 
“Editing Mode,” in which the user can 
both view and edit the graph. At the same 
time, the contained objects themselves 
are allowed to request that their proper¬ 
ties be set to a certain value. A contained 
object could, for example, request to be 
moved to point (x, y), and its foreground 
color set to blue, or to be brought to the 
front. Montage then forwards this request 
to the layout control engine, which then 
has the option of ignoring the request or 
interpreting it if it so chooses. Montage 
exploits the new technology of “window¬ 
less controls” to provide for different 
modes of interaction with the objects. 
This allows Montage to provide a 
“Viewing Mode” in which the user can 
view but not change the graph, and an 
“Editing Mode,” in which the user can 
both view and edit the graph. 

The presentation included an impressive 
live demo, which showed embedding a 
Word snippet into Montage, and then 
embedding a Montage graph into Word. 

Session: Networking and 
Distributed Systems 

Summary by Hui Qin Luo 

SecureShare: Safe UNIX/Windows File 
Sharing through Multiprotocol Locking 

Andrea J. Borr, Network Appliance, 
Inc. 

Dennis Chapman, who made the presen¬ 
tation for author Andrea Borr, employed 
illustrative examples to demonstrate the 
capabilities of SecureShare. SecureShare 
is Network Appliance’s solution to multi¬ 
protocol file sharing between two differ¬ 


ent file systems, UNIX’s Network File 
System (NFS) and the Windows 
Common Internet File System (CIFS) or 
“(PC)NFS.” 

SecureShare is a Multiprotocol Lock 
Manager providing file-sharing capabili¬ 
ties between UNIX clients using NFS and 
Windows clients using CIFS without vio¬ 
lating data integrity. CIFS has hierarchi¬ 
cal locking and mandatory locking func¬ 
tionality that requires file-open and lock 
retrieval before performing any opera¬ 
tions such as reading, writing, or byte 
range locks. Unlike CIFS, UNIX’s NFS 
has a nonhierarchical, file-open deficient 
and advisory locking mechanism. Its has 
no predeclarative functionality that speci¬ 
fies the kind of access mode it needs to a 
file. Therefore, these differences make file 
sharing between the mixed network envi¬ 
ronment difficult, if not impossible. 
SecureShare’s main selling point is the 
preservation of multiprotocol data 
integrity by reconciling the locking 
mechanisms and file-open semantics 
between the two different file systems, 
and multiprotocol oplock (“opportunistic 
locks”) management involving oplock 
requests from NFS to CIFS oplock break. 

CIFS opportunistic locks (with the excep¬ 
tion of level II oplocks) represent the 
equivalent of a file open with Read- 
Write/Deny-All access mode. However, 
access attempts by other clients (using 
either CIFS or NFS) to the oplocked file 
can cause the server to revoke the oplock' 
through an oplock break protocol. The 
client who obtained the oplock gains the 
advantages of read-ahead on the open 
file, cache write operations to files, and 
cache lock requests. In this way, the net- j 
work traffic to the file server is mini- | 
mized. Chapman discussed the oplock 
break protocol in a mixed CIFS and NFS 
environment. When another client wishes 
to access the file, the client’s request is 
suspended. Afterwards, an oplock break 
message is sent to the operating system of 
the CIFS client holding the oplock. The 
client operating system can close the file 
and pipe all the changes of the file stored 
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in the cache to the file server. It can also 
pipe all the cached changes and remove 
all the read-ahead data. It then transmits 
a reply to the fileserver acknowledging 
the break. 

One of the concerns brought up in the 
Q/A session was the handling of a situa¬ 
tion in which a client fails to respond to 
the oplock bread request sent by the serv¬ 
er due to attempted access to the 
oplocked file by NFS. Chapman claimed 
that there is an automatic session timeout 
on the oplock held by the client’s operat¬ 
ing system, which, if triggered, automati¬ 
cally relinquishes the stale batch oplock. 

Session: Networking and 
Distributed Systems 

Summary by: Hui Qin Luo 

Harnessing User-Level Networking 
Architectures for Distributed Object 
Computing over High Speed Networks 

Rajesh S. Madukkarumukumana, 

Intel Corp.; Calton Pu, Oregon 
Graduate Institute of Science and 
Technology; Hemal V. Shah, Intel 
Corp. 

The introduction of high-performance 
user-level networking architectures such 
as Virtual Interface (VI) lays the ground 
work for improving the performance of 
distributed object systems. This presenta¬ 
tion by Rajesh Madukkarumukumana 
examined the potential of custom object 
marshalling using VI, along with issues 
involved in the overall integration of 
user-level networking into high-level 
applications. 

Component-based software like 
Distributed Component Object Model 
(DCOM) uses remote procedure call 
(RPC) mechanisms to facilitate distrib¬ 
uted computing. Although distributed 
computing has matured over time, the 
protocols that are relied on to transport 
data have remained virtually unchanged, 
hindering the overall performance of net¬ 
works such as SANs (System Area 
Networks). The low-latency of user-level 


architectures provides an attractive solu¬ 
tion to the problem in SAN environ¬ 
ments. Madukkarumukumana chose to 
use DCOM and VI as the subjects of his 
research. He presents his methodology in 
integrating the VI based transport and a 
preliminary analysis of the performance 
results. 

The VI architecture provides the illusion 
that each process owns the network; 
many performance bottlenecks are 
bypassed, including the operating system, 
to achieve this low latency, high band¬ 
width connection. At the heart of the 
standard lies two queues for each process, 
one for sending data, the other for receiv¬ 
ing it; the queues contain descriptors that 
state the work that needs to be done. 
Prior to data transfer operations, a 
process called memory registration is 
performed, allowing the user process to 
attach physical addresses to virtual ones. 
Unique memory regions are referenced 
by these address pairs, eliminating any 
further bookkeeping. Two data transfer 
operations are accounted for - the 
standard send/receive operations, and 
Remote DMA (RDMA) read/write 
operations. 

DCOM is a network version of COM, 
used for the development of component 
software. The network extensions in 
DCOM allow for all objects to be 
addressed the same way, hiding their 
location. Encoding and decoding data for 
transfer is called marshalling and unmar¬ 
shalling, respectively; the process of mar¬ 
shalling and unmarshalling creates a stub 
object in the server process, and a proxy 
object in the client process. Basically, 
three types of marshalling are used, but 
the one that Madukkarumukumana dis¬ 
cussed is custom marshalling: it allows 
for the object to dynamically choose how 
its interface pointers are marshalled. 

In order for VI to do its job, the interface 
that DCOM uses to generate the stub and 
proxy, referred to as IMarshal, has to be 
exposed. Specialization in the object 
implementation is used to expose the 


IMarshal interface. By exposing the para¬ 
meters of the IMarshal interface, new 
methods can be written to make use 
of the VI send and receive queues. 
Information can therefore be sent using 
the VI standard, instead of the old UDP 
protocol. Since VI guarantees a certain 
quality of the signal transferred over a 
line, much of the overhead and interrupts 
involved in UDP is eliminated. 

In discussing the results of his research, 
Madukkarumukumana stated that laten¬ 
cy in the signal (for one-way transfer) 
dropped by about 30% to 60% in some 
cases, even only under VI emulation. The 
existence of core VI hardware provides a 
further dramatic increase in perfor¬ 
mance, and an even greater performance 
boost may be expected if new procedures 
catering to distributed computing sys¬ 
tems are implemented within VI (results 
forthcoming). 

Implementing IPv6 for Windows NT 

Richard P. Draves, Microsoft 
Research; Allison Mankin, University 
of Southern California; Brain D. Zill, 
Microsoft Research 

This presentation focused on the imple¬ 
mentation and design details of IPv6 for 
Windows NT as well as the common pit¬ 
falls/challenges encountered in the 
process. IPv6 is the next generation 
Internet Protocol (IP) worked by the 
IETF. The major driver behind it and 
some of its key features were briefly men¬ 
tioned in the paper; however, anyone new 
to IPv6 who wishes to know more about 
its history and the IPv6 specification 
should consult the relevant RFC docu¬ 
ments referenced in the paper. 

The presentation started with an excel¬ 
lent overview of the Windows NT net¬ 
working architecture and how the IPv6 
protocol stack can be/is integrated into it. 
This was followed by a high-level 
overview of the presenters’ IPv6 imple¬ 
mentation and some discussions of four 
challenges/issues encountered and the 
specific solution used. The presentation 
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ended with some notes on the implemen¬ 
tation’s performance. 

The segment on NT networking internals 
was very informative, especially for 
novices. The details on the interfaces 
(documented or undocumented) and 
protocols presented, along with the help¬ 
ful references mentioned in the paper, 
will prove useful for anyone trying to 
implement a different network protocol 
stack for NT and even for Windows 95 
(due to similar network architectures). 
The integration of IPv6 into this net¬ 
working architecture was also highlight¬ 
ed. Mainly, a Winsock DLL module was 
added to provide user-level socket func¬ 
tionality for IPv6 addresses, and a new 
TCPIP protocol driver to replace the 
IPv4. The implementation was “single 
stack,” supporting only IPv6, and though 
not efficient was useful in isolating prob¬ 
lems in the IPv6 stack during testing. The 
logical layout of the implementation was 
divided into three layers similar to IPv4 - 
the link layer, the network layer (IP), and 
the transport or upper layer which 
includes protocols such as TCP, UDP, and 
ICMP. 

Four noteworthy problems and their 
implemented solutions were discussed. 
They range from inefficiencies in lower- 
level network device handlers during a 
receive cycle to deadlock avoidance 
issues. 

Performance measurements for the 
implementation were taken using TCP 
throughput as the indicator metric and 
compared to the IPv4 stack. Results pre¬ 
sented showed marginal performance 
degradation with the IPv6 stack (2.5% 
over lOMb/s LAN), and somewhat higher 
than expectations (1.4% based on 
increased IPv6 header length). This is to 
be expected, as the developers never 
intended this to be an optimized imple¬ 
mentation, but rather as a base for fur¬ 
ther research and to give Microsoft the 
push for a product release in the future. 
Whether we will see better performance 
results in Microsoft’s official product 


implementation of IPv6 is still to be 
determined. Comparative performance 
measurements against other IPv6 imple¬ 
mentations (Solaris, Digital Unix, BSD 
variants etc.) were left out. The metric of 
comparing each implementation’s relative 
performance to its IPv4 counterparts can 
be used as an indicator. Direct IPv6 TCP 
throughput comparisons might not be 
fruitful because of differences in the 0/S 
architecture each implementation was 
targeted for, unless IPv4 performance was 
similar across these platforms. Source 
code size comparisons were done against 
another publicly available IPv6 imple¬ 
mentation (INRIA IPv6). 

“Great sample code” is available at 
<http://research.microsoft.coin/msripv6> for 
anyone who wishes to dabble in Windows 
NT network protocol development or 
have a starting code base for further IPv6 
research and experimentation. A more 
full-fledged release with security, authen¬ 
tication, and mobility support is expected 
to be available in the future. 

Session: Real-time Scheduling 

Summary by Jason Pettiss 

A Soft Real-time Scheduling Senrer on 
Windows NT 

Chih-han Lin, Hao-hua Chu, and 
Klara Nahrstedt, University of Illinois 

Hao-hua Chu spoke about his group’s 
implementation of a software realtime 
CPU scheduler for Windows NT. NT 
schedules applications indiscriminately 
based on multi-user time-sharing. 
Multimedia performs poorly under these 
conditions, especially if non-time-sensi- 
tive-conscious but CPU-hungry tasks like 
compilation are occurring in the back¬ 
ground. The scheduling server is a dae¬ 
mon from which applications can request 
and acquire periodic processing time. 

The scheduler requires no kernel modifi¬ 
cations, uses the rate monotonic algo¬ 
rithm, supports multiple processors 
(SMP model), and provides guarantees 
for timeshare processes so that they aren’t 


starved by realtime tasks. Chu says there 
is “reasonable” performance at this point, 
the main problem being limited overrun 
protection due to the fact that the sched¬ 
uler itself is a process and sometimes isn’t 
woken up on time by NT. 

The architecture consists of a broker, 
which handles reservation requests, 
builds a dispatch table, and fills the avail¬ 
able slots of the table. The dispatcher is 
in charge of reading the table and 
responding appropriately. The dispatch 
table is configurable for the number of 
processors, the number of available slots, 
and the time-slice of slots. Dispatching 
occurs by changing the thread and 
process priority of participating applica¬ 
tions between idle and highest priority 
realtime (1-31). 

To test, Chu’s team used a dual Pentium 
200 with 96 MB RAM (an HP Vectra 
XU). Time-slice was set to 20ms. They 
ran two processes running MPEG 
decoders at FPS, one Visual C++ compi¬ 
lation of the MPEG decoder, and four 
processes running computations of sine 
and cosine tables. Dispatch latency 
worked out to be about 640 microsec¬ 
onds, which was longer than they would 
have liked, but not too large to disrupt 
scheduling. Performance of the two time- 
sensitive processes was improved, Chu 
noted. 

The main problem, reiterated Chu, was 
that NT sometimes did not wake up the 
dispatcher on time. Also, the dispatcher, 
being an NT process itself, cannot pre¬ 
empt real-time processes. This means ‘ 
there is weak overrun protection. The 
provided NT timers weren’t accurate 
enough, so they are using a Realtime | 
Extension (RTX) by Venturcom to get 
under 1ms resolution. 

They have much future work planned. 
Support is planned for varying processing 
time per period and for a process service 
class, similar to ATM traffic classes. They 
hope to run conformance tests. Also, they 
would like to adapt a multimedia decoder 
to increase reservation or decrease quality 
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as necessary. An additional feature, prob¬ 
ing and profiling, could be added to fig¬ 
ure out how much processing time to 
reserve on a per-application basis. 

Vassal: Loadable Scheduler Support for 
Multi-Policy Scheduling 

George M. Candea, Oracle 
Corporation; Michael B. Jones, 
Microsoft Research _ 

George Candea presented Vassal, a system 
that utilizes loadable schedulers to enable 
multi-policy, application-specific sched¬ 
uling on Windows NT. He led off with 
the example of a speaker late for a pre¬ 
sentation (an application) that knows 
where it needs to be and when, and a cab 
driver (the OS) that can get him there on 
time if he can communicate with him. 
Windows NT is more like a cab driver 
who hasn’t learned English yet - the 
operating system multiplexes the CPU 
among tasks, unaware of their individual 
scheduling needs. 

Since no single algorithm is good enough 
for all task mixes, explained Candea, a 
compromise would be to hardcode more 
than one scheduling policy into the ker¬ 
nel. But even better would be a dynami¬ 
cally extensible set of policies, made pos¬ 
sible by separating policy (scheduling) 
from mechanism (dispatching). This lets 
a developer concentrate on coding policy. 
It also would allow different applications 
to communicate with their preferred pol¬ 
icy to bargain for scheduling time. 
Custom schedulers are special Windows 
NT drivers that coexist with the default 
NT scheduler, and which should have 
negligible impact on global performance. 

Candea then reviewed the current state of 
Windows NT scheduling. The basic 
schedulable unit is the thread, which 
acquires CPU time based on priority lev¬ 
els of two classes: variable, which uses a 
dynamic priority round-robin, and real¬ 
time, which uses a fixed priority round- 
robin. Interrupts and deferred procedure 
calls (DPCs) have precedence over 
threads, so scheduling predictability is 


limited. Scheduling events are triggered 
by: the end of a thread quantum, priority 
or affinity changes, transition to wait 
state, or a thread waking up. 

NT timers use the hardware abstraction 
layer (HAL), which provides the kernel 
with a periodic timer of variable resolu¬ 
tion. Candea noted that most HALs have 
resolution between 1 and 15 ms, but 
some HALs are worse than others - some 
can be set to only powers of two, while 
others are fixed at 10 ms. This is certainly 
another limitation to scheduling with any 
policy under NT. 

Vassal separates policy from mechanism. 
While the NT scheduler consists of 
thread dispatch and a default scheduler, 
Vassal consists of many schedulers (poli¬ 
cy modules) arranged hierarchically and 
a separate dispatch module in charge of 
preempting and awakening threads. 
Standard NT policies remain in the ker¬ 
nel so that applications with no special 
needs are handled as usual. 

The schedulers register decision making 
routines with the dispatcher. The dis¬ 
patcher invokes these when scheduling 
events occur. Threads can communicate 
with schedulers to request services. These 
new features require some interface mod¬ 
ifications, with the addition of three sys¬ 
tem calls. 

As proof-of-concept, the Vassal team 
implemented a sample scheduler that can 
be loaded in addition to the default NT 
policy. The sample allows threads to get 
scheduled at application-specified time 
instances, which is simplistic, Candea 
admitted, but demonstrates potential for 
more interesting time-based policies. 

Minimal NT kernel changes were 
required: they added 188 lines of C code, 
added 61 assembly instructions, and 
replaced 6 assembly instructions. The 
scheduler itself was only 116 lines of C 
code, required no assembly language, and 
they only needed to code policy. 
Performance results showed that it was 
no slower if no specialized scheduler was 


loaded, and there was only 8% overhead 
with their untuned prototype. Results 
showed that with the special scheduler, 
the predictability of periodic wakeup 
times significantly improved, and there 
were no longer early wakeups. There were 
a few slightly late wakeups (still less late 
than without the prototype loaded), and 
these were caused by unscheduled events 
such as interrupts and DPCs. 

Candea emphasized the Vassal take- 
homes are that it demonstrates the viabil¬ 
ity and positive impact of loadable sched¬ 
ulers, and that it frees the OS from antici¬ 
pating all possible application scheduling 
requirements. It also encourages interest¬ 
ing research in this area by making it easy 
to develop and test new policies, and 
doesn’t adversely affect the OS. 

Some related work is Solaris, which maps 
scheduling decisions onto a global priori¬ 
ty space; extensible OS work like Spin, 
Exokernal, or Vino, and hierarchical 
schedulers like UTAH CPU or UIUC 
Windows NT Soft Real-Time scheduler. 

Many questions followed. Someone sug¬ 
gested that two different schedulers must 
be compatible or there will be trouble. 
Candea agreed that this was an interest¬ 
ing problem that could be solved by 
allowing schedulers to talk to each other 
and “negotiate” or to use their descrip¬ 
tions and decide if a conflict will occur. 
Another question was that a driver has 
limited visibility into the NT kernel, and 
does this affect the power of a scheduler? 
The answer is yes, ideally these special 
drivers would be able to see into the ker¬ 
nel data structures for real power. The 
moderator asked what can be done about 
predicting DPCs and interrupts. Candea 
didn’t think that was necessary, noting 
that these are best left to perform their 
crucially important tasks when they 
need to. 

<http://pdos.lcs.mitedu/'-can(lea/research.html> 

<http://research.mlcrosoft.com/~mbj> 
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Session: NT Futures 

Tom Phillips and Felipe Cabrera, 
Microsoft Corporation 

Summary by Kevin Chipalowsky 

Felipe Cabrera and Tom Phillips demon¬ 
strated the upcoming Windows NT 5.0 
operating system and the NT Services 
for UNIX add-on. The two-hour session 
was very open, informal, and at times 
emotional for some in the audience. 
Microsoft gave a presentation while 
inviting just about any type of question 
regarding the future of their flagship 
operating system. Cabrera and Phillips 
fielded very spirited questions and 
comments. 

Phillips began his NT 5.0 presentation by 
describing its new support for upgrading 
from Win 9x. The setup program first 
scans a system for compatibility before 
installing anything. It will now migrate 
applications as part of the upgrade 
process, using plug-ins to support third- 
party software. The system configuration 
is also preserved during the transition to 
NT. 

Next, Cabrera talked about the new vol¬ 
ume-management infrastructure. The 
new version of Windows NT will have 
many new storage management features. 
In most cases, hard-drive partitions can 
be manipulated without requiring a 
reboot. For example, partition size can 
grow and shrink dynamically. There are 
also new security features, such as a reli¬ 
able “change” journal and file encryption. 
In response to a question about the type 
of encryption, Cabrera explained that it 
uses public key cryptography and is 
designed to prevent thieves from examin¬ 
ing data on a stolen laptop. 

Cabrera also talked about the new file- 
based services sported by NT 5.0. It pro¬ 
vides a new content indexing tool, which 
can be used to search for files based on 
their content instead of just their file¬ 
name. It tracks common types of embed¬ 
ded file links and updates them when a 
data file is moved to a different volume 


or even a different machine. There is also 
a new automated recovery system to 
revive a computer that otherwise will 
not boot. 

The speakers then presented NT Services 
for UNIX. Microsoft developed it in 
response to the growing adoption of NT 
by previous UNIX users. It will be avail¬ 
able for Windows NT 4.0 with Service 
Pack 3 for $149 per client. It is in beta, 
and anyone interested in being a beta 
tester should email <gregsu@microsoft.com> 
with “sfubeta” as the subject. 

NT Services for UNIX will make an NT 
machine feel more like a UNIX one. It 
allows users to access NFS partitions like 
any NTFS of FAT partition. A new Telnet 
client and server are also included, so 
administrators can remotely Telnet into a 
Windows NT system and run console- 
based applications. Microsoft has licensed 
a Korn shell implementation and a few 
dozen familiar UNIX tools from MKS. 
The audience loudly applauded this part 
of the presentation. 

Next, Cabrera and Phillips revealed stor¬ 
age features; the new Microsoft 
Management Console (MMC) was the 
center of attention. It is a management 
container that provides Microsoft and 
third-party developers the opportunity to 
plug in software to manage just about 
anything. 

The first demonstration was of RAID 5.0 
support. One hard drive of a stripe vol¬ 
ume was removed and later plugged back 
into the system. Although the underlying 
file system seemed to handle the inten¬ 
tional fault, MMC simply crashed and 
the computer needed a reboot. After this 
small setback, the demo moved on. 

Hierarchical Storage Management (HSM) 
is another feature new to NT 5.0. It 
makes use of the observation that the 
most commonly used files are usually the 
most recently used files. When a hard- 
drive partition becomes full, the filesys¬ 
tem offloads older files to a tape backup 
system to make free hard-drive space 


available. Although Microsoft is not the 
first to attempt to build HSM support 
onto NT, they believe they will be the 
most successful. They have complete con¬ 
trol over the operating system and can fix 
all of the related utilities that would oth¬ 
erwise have difficulty with the extremely 
long latency that results from trying to 
open certain files. 

Networking in NT 5.0 has also received 
an overhaul. As with volume manage¬ 
ment, most network configuration 
changes can now be made without 
rebooting the system. Microsoft also 
claims an improved programmable net¬ 
work infrastructure. The TCP/IP stack is 
also enhanced; it runs faster and supports 
security and QoS protocols. 

Large Installation 
System Administration 
of Windows NT 
Conference 

SEATTLE, WASHINGTON, 


iugust 6-8,1998 


INVITED TALK 

Windows Management Roadmap 

Nikhil Joshi and Tom Phillips, 
Microsoft Corporation 

Summary by John Holmwood 

This talk, which was intended to provide 
a roadmap of the changes Microsoft is 
making to the manageability of Windows 
NT, was broken into two parts. Tom 
Phillips talked about the Windows 
Management Architecture (WMA) and 
Nikhil loshi discussed the NT File System 
(NTFS). 

The WMA provides the management 
framework and structure to assist system 
administrators in managing Windows 
NT. It includes the suite of applications 
formerly called Web Based Environment 
Management (WBEM). It is based on the 
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Windows Management Instrumentation 
(WMI) object model. Phillips demon¬ 
strated several applications that use the 
WMI: 

Disk performance. Phillips demonstrated 
the WMI object model using a script pro¬ 
gram developed by Computer Associates. 
He noted that supporting the WMI inter¬ 
faces is a requirement for getting device 
drivers certified for NT 5. 

Microsoft management console. Phillips 
demonstrated the Common User 
Interface in the new management con¬ 
sole. He noted that it was possible to 
group tools appropriate for a particular 
management function, such as database 
management, and save the tool set so that 
the administrators will have a specific set 
of tools appropriate to their function. 

Windows Scripting Host. Phillips demon¬ 
strated the new scripting architecture, 
Windows Scripting Host, by resetting all 
network adapters in a sub-net without 
using the GUI. This demo drew cries of 
“about time” from the audience. 

Automatic software installation. Using the 
new Policy Manager, Phillips created a 
policy to have an application automati¬ 
cally upgraded on a user s desktop. He 
used the Active Directory to find the file 
share that contained the new application. 
When he logged on as that user, the new 
application was automatically down¬ 
loaded to the workstation. This drew 
questions regarding license management 
and network bandwidth requirements, 
which he dodged. 

At this point, Nik Joshi took over the pre¬ 
sentation. He provided some historical 
background on the evolution of 
Microsoft filesystems, then talked about 
the new NTFS. The biggest news was the 
changes between NT 5 and NT 4 NTFS. 
The NT 5 installation process converts 
the old NTFS to the new one automati¬ 
cally. Once the file system has been con¬ 
verted, it cannot be converted back to 
the NT 4 version. This means that the NT 
5 NTFS should not be used on a dual 


boot (NT 4/NT5) computer. NT 5 should 
be installed on a separate machine. 

NT 5 has incorporated the Veritas Logical 
Disk Manager and Eastman HSM, as well 
as file encryption and disk quotas. Joshi 
provided three demonstrations: 

Volume manager. Joshi first demonstrated 
the Disk Manager application. The capa¬ 
bilities will be familiar to any UNIX sys¬ 
tem administrator; all the Unices I know 
now include the Veritas Logical Disk 
Manager. However, judging by the audi¬ 
ence reaction, NT sysadmins will appreci¬ 
ate the functionality. 

Plug and play. Joshi demonstrated the 
new plug and play capabilities by 
installing a PCMCIA NIC into his laptop 
while it was running. The system detect¬ 
ed the new card and loaded the correct 
drivers and protocol stack automatically. 
It simply worked before our eyes. 

Resource Kit. In order to demonstrate the 
tool set incorporated into the NT 5 
Resource Kit, Joshi demonstrated the 
Nettest tool, which he characterized as 
Ipconfig on steroids. Microsoft has done 
significant work to make the Resource Kit 
easier to use. 

REFEREED PAPERS 

Session: Management and 
Monitoring 

Summary by Chris Barnash 

Patch32: A System for Automated Client 
OS Updates 

Gerald Carter, Auburn University 

Patch32 was created to “provide for com¬ 
pletely automated, remotely administered 
updates to Microsoft’s 32 bit operating 
systems.” In addition, the goals for 
Patch32 included the ability to support 
Windows 95 and Windows NT with the 
same update method, and the ability to 
provide an update method that is free. 

The Patch32 system is made up of two 
main components, the server and the 
client. The server in Carter s implementa¬ 


tion consists of Samba running on a 
Sparc Ultra 170. On this server is a share 
that provides a central location for the 
distribution of client updates. The client 
side of Patch32 consists of a Perl for 
Win32 script, which is executed by the 
client during the boot process. 

The Patch32 Perl script is charged with 
several tasks. First, it determines what 
version of the operating system is run¬ 
ning on the client. On the basis of this 
information, it determines the location of 
the patches on the server, and the method 
of installation. (The installation method 
differs between Windows 95 and 
Windows NT.) Next, it parses a file con¬ 
taining a list of patches stored on the 
server to determine which patches are 
available for installation. For each patch 
in the list, the Patch32 Perl script queries 
the client s registry to determine if the 
patch is already installed. If it is not 
installed, it installs the patch, otherwise it 
continues down the list. Upon comple¬ 
tion, a message is displayed providing 
information on the installation. If the 
client is Windows 95, the patches will 
take effect after the next reboot. If the 
client is Windows NT, the Resource Kit s 
shutdown utility is used to reboot the 
system. 

Documentation and source code for 
Patch32 can be found at 
<http://www.eng.fsu.edu/users/cartegw/Patch32>. 

Monitoring Utilization in an NT 
Workstation Lab 

Paul Kranenburg, Erasmus University, 
Rotterdam 

Paul Kranenburg discussed his solution 
for monitoring usage in the computer 
labs at Erasmus University - a Windows 
NT utmp service. 

The utmp service relies on NTs built-in 
auditing features to document LOGON 
and LOGOFF events. Specifically, SUC¬ 
CESSFUL LOGON and SUCCESSFUL 
LOGOFF events are used to identify 
when a particular computer is being 
used. 
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The data gathered by the utmp service 
can be used in one of two ways. Short¬ 
term data provides for immediate notifi¬ 
cation of computers that may be down. 
An on-screen map displays all of the 
workstations with color codes that identi¬ 
fy the status of the computers. A kiosk 
showing this map is also set up at the 
entrance of the labs to assist in finding 
available computers. The long-term data 
statistics can be graphed to provide uti¬ 
lization reports, which in turn are used to 
determine if the current number of 
workstations is sustaining the needs of 
the department. 

The author can be reached at 
<kranenburg@few.eur.nl>. 

INVITED TALKS 

Summaries by John Holmwood 

Windows NT - A New 0/S that 
Architecturally Isn’t so New 

Mark Russinovich, Systems Internals 

Mark Russinovich maintains the Systems 
Internals Web site, a resource for 
Windows NT and Windows 9x utilities. 
He is also the author of the NT Internals 
column in Windows NT magazine. 
Russinovich opened his presentation with 
a short history of the development of 
UNIX and Windows NT, and then com¬ 
pared the core services of Windows NT 
and UNIX. (Russinovich carefully point¬ 
ed out that he was talking about the NT 
exec, not the Win32 APIs that are layered 
on top of the exec, and that he was talk¬ 
ing about UNIX in general, not any spe¬ 
cific implementation.) The areas of com¬ 
parison were: 

Architecture overview. The main architec¬ 
tural difference is that UNIX does not 
have a HAL. Windows NT is so much like 
VMS that it is possible to follow what NT 
is doing internally by using the VMS 
internals documentation. He provided a 
Rosetta Stone for translating VMS docu¬ 
mentation to NT. 


Namespace. The Object Manager defines 
NT’s namespace. This makes the name- 
space uniform. The UNIX namespace is 
defined in terms of the filesystem. It 
doesn’t need an Object Manager. 
Russinovich believes the NT method is 
superior. 

Process management. NT process manage¬ 
ment includes processes, threads, and a 
scheduler. The NT kernel mode is fully 
preemptive. In this category, the Unices 
vary significantly. A UNIX process is sim¬ 
ilar to an NT file handle. The kernel is 
cooperatively preemptive. 

Memory Management. NT and UNIX are 
similar here. 

Security. Both NT and UNIX are rated C2 
secure systems. NT uses ACLs, users, and 
groups. The groups are nestable. There 
are about 20 different privileges. Security 
is handled by the Object Manager. UNIX 
has a simpler security model based on 
Users and Groups. ACLs have been added 
to some versions. Security is applied to 
files. This difference is due to the differ¬ 
ences noted in the namespace section. 

Synchronization and I PC. Similar. 
Russinovich moved over this area quickly. 

I/O. NT I/O is centered around the file 
object. This allows a layered driver archi¬ 
tecture that can support asynchronous 
operations including hardware interrupt 
support. Plug and play capability is com¬ 
ing in NT 5. UNIX I/O is centered 
around vnode/inodes. Traditional I/O is 
synchronous. Some versions have split 
interrupts to support asynchronous 
events. 

File disk cache. NT has a single global 
cache. The virtual file cache is mapped 
into the kernel memory cache. UNIX 
uses disk block cache. Some of the newer 
versions use the same cache model as NT. 

Networking. Lots of interfaces, lots of 
protocols. The difference is the layered 
model in NT. Only streams are layered in 
UNIX. 


Integrated database. NT has a 
Configuration Manager Registry. UNIX 
uses config files. 

Extensibility. In NT, all drivers are 
dynamic. There is a rich set of operating 
system APIs for drivers. The layered I/O 
allows drivers to add functionality. UNIX 
supports dynamically loaded extensions. 
The degree of operating system support 
services varies from very limited to a set 
approaching those provided by NT. 

Portability. In terms of CPUs supported, 
UNIX is available on everything. NT is 
only available on x86 and Alphas. 

Russinovich finished his presentation by 
tackling the question, “Which is better - 
UNIX or NT.” He put up charts of pub¬ 
lished Specweb and TCP-C benchmarks. 
His conclusion was that NT is as good as 
UNIX for small- to medium-sized servers 
and will get better in the larger-server 
space over time. 

NT 5.0 Migration Strategies 
at Microsoft 

Curtis Cummings, Microsoft 
Corporation 

Curtis Cummings is responsible for IT 
support at Microsoft. He started work on 
Windows NT when it was the Cairo pro¬ 
ject. He is responsible for the rollout of 
NT 5 at Microsoft, which runs its entire 
company on Windows NT. He has 150 
NT servers running the Beta 1 NT 5 soft¬ 
ware. The talk included a great deal of 
light banter between the speaker and the 
audience. Todd Needham of Microsoft 
fielded marketing questions for 
Cummings. Since Curt had a microphone 
and Todd didn’t, this occasionally gave 
the impression of Curt acting as Todd’s 
puppet. 

Cummings started his talk by describing 
the Internal Technology Group’s (ITG) 
environment, noting that his clients run 
“dog food,” Microsoft’s term for Alpha 
code. Two years ago, Microsoft didn’t use 
DNS internally. In response to a question 
from the audience, Cummings noted that 
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only his new administrators use the 
Microsoft GUI interface to DNS. 

Everyone else uses the command line 
interface. 

He then described issues in migrating to 
NT 5 using the ITG experience as an 
example. 

Use what you ve got. Most of your infra¬ 
structure can continue to be used. You 
will probably have to beef up the server 
hardware. Cummings shared the ITG 
Network Plan to test NT 5 RAS services. 
Wlien asked if Microsoft would be shar¬ 
ing the results of the ITG test, Todd stat¬ 
ed that they would be publishing their 
acceptance test criteria. 

Pick a migration approach. Cummings 
described ITG s migration plan in detail. 
The schedule has slipped. His slides 
showed ITG s rollout completing by the 
end of 1998. This has been changed to 
coincide with the official release of 
Windows NT 5. They plan is to have all 
of their servers using NT 5 in production 
when NT 5 is officially released. 

Namespace design. Cummings devoted a 
quite a bit of time to the new DNS-like 
domain structure that Microsoft has set 
up for NT 5. He believes this is one of the 
biggest changes for people who are used 
to WINS. 

Tools. According to Cummings, the 
Microsoft Management Console (MMC) 
is “a way cool tool.” On the other hand, 
he uses SMS because he is not given any 
other choice. ITG had to build their own 
tools for managing NT 5. The MMC 
gives them a consistent interface for the 
tools they developed. Microsoft sent the 
ITG staff to Perl courses, and now most 
of their internal tools are written in Perl. 
There was a lot of support for an audi¬ 
ence request to have access to the ITG 
tools. 

Policy manager. Cummings believes that 
the policy manager in NT 5 is a “big 
deal” for the support staff in terms of 
both administrative support for it and 


planning and definition of appropriate 
policies. 

Planning your Infrastructure. Cummings 
talked about how to plan your server 
infrastructure. Bandwidth requirements 
will be the major issue. There was a sug¬ 
gestion from the audience that ITG 
should do its bandwidth testing on the 
India link (ITG s slowest link, 64KB). 

Migration Order. Microsoft’s migration 
order looks backward; they’re doing the 
most critical components first. This is 
required to initiate the new services. 

Their fallback position is “God help us!” 

Security. A member of the audience from 
MIT confirmed that Microsoft is working 
closely with MIT to make Microsoft’s 
Kerberos interoperate with the standard 
implementation. 

Bringing the “Real” Internet to 
Windows NT 

Bo Ahiberg, MetaInfo, Inc. 

Bo Ahlberg was the chief technology offi¬ 
cer at MetaInfo. MetaInfo has ported the 
IETF reference version of BIND and 
sendmail to Windows NT. MetaInfo was 
recently acquired, and Ahlberg is not 
staying with the new organization. He 
noted that the engineer who actually did 
the port wasn’t allowed to do the presen¬ 
tation, so we were stuck with him. His 
talk was subtitled “Making NT into a Real 
‘Forking’ OS.” 

The first third of this talk was on the gen¬ 
eral problems MetaInfo encountered in 
porting UNIX applications to NT: a fork 
is not a thread, a file descriptor is not a 
handle, there are no common tools, and 
a daemon is not a service. 

He then briefly described porting tactics: 

Start from the beginning and design with 
the other architecture in mind. 

Fix what you’ve got; this teaches you your 
design weaknesses. 

Starting over is sometimes cheaper than 
using what you’ve got; you can design in 
portability. 


In the final section of the talk Ahlberg 
described the port of BIND and sendmail 
- or, more accurately, the mistakes, the 
successes, and the lessons learned. 

BIND. They created a service wrapper for 
BIND to make it fit the NT architecture, 
and modified the error code to use the 
Event Log. This allowed the BIND dae¬ 
mon to run as a child process. The 
lessons learned were that NT-ifying 
UNIX code is wrong; maintaining com¬ 
patibility with the “owner” of the code is 
a “good thing”;you shouldn’t mix MFC 
with services; and sometimes it’s easier to 
fix the environment than it is to fix the 
program. 

sendmail. Sendmail would not work 
without a fork architecture, which NT 
didn’t have. After several tries, the project 
team created a fork environment for NT. 

Ahlberg ran out of time before compet¬ 
ing all of his slides. He rushed through 
the conclusion that it is possible to port 
UNIX applications to NT but the work 
needs to be planned and scoped very 
carefully; then you need to “UNIX-ify” 
NT, not the reverse. 

PANEL 

Windows NT Tips and Tricks 

Robert O’Brien, Microsoft 
Corporation; Brian O'Neil, Mike Wei, 
and Andie O’Brien, Collective 
Technologies 

Summary by Chris Barnash 
The Windows NT graphical user interface 
often leads system administrators to 
believe that it is impossible to run head¬ 
less, remotely managed, NT servers. But 
according to Robert O’Brien, it is possible 
to deploy NT servers in this fashion. 

O’Brien’s talk, entitled “Windows NT 
Lights Out Operation,” focused on the 
setup and update of remotely managed 
NT servers. O’Brien outlined five major 
steps for deployment: (1) Choose a sys¬ 
tem console solution. Several hardware 
vendors, such as Compaq, DEC, HP, and 
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Intel, offer Integrated Remote Console 
Boards. (2) Choose a telnet/secure shell 
solution. Microsoft is working on 
Services for UNIX, which will include 
this. Also, several third-party vendors 
offer telnet/secure shell services, includ¬ 
ing Seattle Lab and DataFellows. (3) 
Choose a remote Win32 solution, such 
as Carbon Copy (Compaq), PCAnywhere 
(Symantec), Remote Possible (CA 
Associates), and Virtual Network 
Computing (ORL). (4) Develop an 
OEM-unattended installation process. 
Two options exist for this step. Microsoft 
has developed a process for unattended 
installs, which can be found at 
<http://www.microsoft.com/ntworkstation/ntwnew/ 
info/deployguide.htm>. The other option is to 
use a disk cloning technique, like Ghost. 
(5) Choose a network management/mon¬ 
itoring solution. This can be accom¬ 
plished with Microsoft Systems 
Management Server, Tivoli, Computer 
Associates Unicenter TNG, or Hewlett 
Packard OpenView. 

O’Brien s paper on the Windows NT 
Lights Out Operation, slides from the 
presentation, and tools to assist adminis¬ 
trators with deployment can be found at 
<ftp://ftp.msftlabs.com/loop>. Additional 
information on Windows NT manage¬ 
ment can be found at 
<http://www.microsoft.com/management>. 

Brian O’Neil discussed Windows NT 
Terminal Server, a redesign of Windows 
NT Server backend that supports thin 
clients. Windows NT Terminal Server can 
provide the use of Windows NT on 
clients that cannot run Windows NT. The 
idea is very similar to Xterms in the 
UNIX world. Thin clients (such as a 386) 
can run the Windows GUI without the 
need to actually run the full-blown 
Windows NT on the desktop. More infor¬ 
mation on Windows NT Terminal Server 
can be found at <http://www.microsoft.com/ 
NTServer/Basics/TerminalServer/clefault.asp>. 

Mike Wei discussed UNIX and Windows 
NT filesharing with respect to interoper¬ 
ability, performance, security, and name- 
space consistency. The most interesting 
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part of the discussion was that of 
Microsoft’s Distributed File System (DFS) 
for Windows NT. DFS is similar to NFS 
under UNIX. It allows an administrator 
to set up mount points instead of shares 
assigned to different drive letters. DFS 
will be included in Windows NT 5.0 and 
is available as a download for Windows 
NT 4.0. For more information on DFS, 
see <http://backoffice.mjcrosoft.com/downtrial/ 
moreinfo/dfs.asp>. 

Andie O’Brien discussed several mecha¬ 
nisms for monitoring multiple NT 
servers. The Performance Monitor can be 
used to monitor several aspects of a com¬ 
puter, including processor, memory, and 
page file utilization. Another built-in NT 
tool is the Event Log. Keeping an eye on 
the logs can help pinpoint problems. 
O’Brien also gave pointers to several 
third-party monitoring programs from 
HP, NetiQ, and Heroix. 

INVITED TALK 

NT 5 Administration: Change and 
Configuration Management 

Dan Plastina and Mike Cherry, 
Microsoft Corporation 

Summary by John Holmwood 

This presentation, the final session of the 
conference, was meant to be a demon¬ 
stration and discussion of the behind- 
the-scenes technology that supported the 
new Change and Configurations 
Management in Windows NT 5. 
Predictably, most of the demonstrations 
did not work the first time. 

Unfortunately, most attendees missed 
some or all of the talk, which was liberal¬ 
ly interspersed with lively audience dis¬ 
cussion after each demo. In fact, Remy 
Evard, co-chair of the conference, had to 
ask the audience to hold off on questions 
so that the formal part of the talk could 
be completed in two hours. Wlien I left 
after three hours to catch my plane 
home, Plastina and Cherry were still 
fielding questions from the few people 
left in the audience. 


NetPC boot. The first demonstration was 
the NetPC network boot. This failed the 
first time they tried it, but eventually, 
with Cherry working in the background 
while Plastina talked, they managed to 
get it working. The functionality requires 
a special NIC card that supports the 
PXWE protocol (NetPC & PC98) on the 
client and the new Active Directory, DNS, 
and DHCP services on the server. The 
functionality is automatic with NT 5 
DHCP; other DHCPs should work with 
the new NIC cards. 

The boot sequence starts by running 
fdisk on the client hard drive. Dual boot 
configurations are not compatible with 
this feature. Plastina solicited feedback 
from the audience on the need to support 
dual-boot systems; the response was 
mixed. 

Application management capabilities. 
During this demonstration. Cherry was 
able to automatically install an applica¬ 
tion by selecting the application. 

However, his attempt to demonstrate that 
the application could be installed simply 
by invoking a document created by the 
application failed. 

A request came from the audience for 
this capability to be included in NT 4.5. 
Mike and Dan pointed out that half the 
problem was in the client and half in the 
server. On the server side, the solution 
relies heavily on NT 5 technologies such 
as Active Directory, Kerberos, and 
caching. There is little chance of these 
functions appearing in an NT 4 service 
pack. 

Policy management. The policy manage¬ 
ment user interface is likely to change 
before NT 5 ships. Policy will became 
part of the property of the container. 
Much of Policy Editor functionality is not 
scriptable. (Plastina regrets this decision). 
Policies are more consistent than in NT 
4, but user permissibles aren’t interfered 
with. 
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Synchronization manager. The synchro¬ 
nization manager manages the client-side 
cache. Plastina tried, unsuccessfully, to 
demonstrate the system synchronizing a 
file. He did demonstrate the synchroniza¬ 
tion options available on the system. The 
synchronization function requires 
Windows NT 5 server as the fileserver. It 
uses the SMB redirector so wont work 
with NFS or Novell. The speakers dodged 
the question of testing the functionality 
with Samba. 

Roaming profiles. Plastina commented on 
the effort that has gone into Office 2000 
to make it an “awesome” roaming appli¬ 
cation. The application now understands 
the difference between user data (e.g., my 
dictionary) and application data. During 
the questions after this demo, a lot of 
hostility regarding roaming profiles came 
up. This appeared to be a case of killing 
the messenger. Plastina handled the shots 
very well. Roaming profiles are useful for 
the segment of user environments where 
users can add their own applications. For 
more locked-down environments, poli¬ 
cies in NT 5 can redirect where files are 
obtained from without using roaming 
profiles. 

There was also a lot of hostility over 
Microsoft not following its own applica¬ 
tion guidelines with respect to DLLs. 
Plastina’s response was that Microsoft 
application groups could no longer 
change O/S DLLs. This will eliminate 
some of the problem of applications 
interfering with each other. 

Plastina would really like samples of real 
login scripts so that Microsoft can under¬ 
stand what workarounds for NT 4 people 
are using. This will help make the NT 5 
functionality better. Send scripts with 
commentary to <danpl@microsoft.com>. 
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Session: Advances in Payment 
Technology 

Summary by Matthew Hohifeld 

Electronic Commerce and the Street 
Performer Protocol 

John Kelsey and Bruce Schneier, 
Counterpane Systems 

Bruce Schneier began his presentation by 
letting the audience know that, through 
his error, the version of the paper in the 
proceedings was not the correct one, 
which is available at 
<http://www.usenix.org/publications/library/ 
proceedings/ec98> and at 
<http://www.counterpane.com/street_performer.html>. 

The premise of this work is that none of 
the currently available systems for pro¬ 
tecting intellectual property (IP) will be a 
full solution in a world where the dupli¬ 
cation of a work is simple and nearly 
cost-free. As technologies for copying 
become cheaper, and we begin to rely 
more on digital delivery systems for intel¬ 
lectual property, the notion of copyright 
itself becomes invalid. Without copyright 
protection, the creation of works will 
diminish, and ultimately the public will 
suffer. As a possible solution to this prob¬ 
lem, Schneier suggested that new works 
could be funded on an escrow system. 
This would help restore the incentive for 
the creation of works, even when the 
works are then released as part of the 
“public good.” He provided an exliaustive 
list of the currently used (or designed) 
methods for protection of IP, along with 
the perceived flaws of each. The list 
included both secure perimeter schemes 
and traitor tracing schemes; law-based 
solutions; and alternatives such as adver¬ 
tising, product placement, and govern¬ 
ment funding. 


By suggesting an analogy between “con¬ 
sumers” of IP and donations to a street 
performer, Schneier provides the basis for 
a new payment method, dubbed the 
Street Performer Protocol. Using a bank 
or publisher as a trusted third party, the 
Street Performer Protocol simply has the 
creator of a work request a specific mini¬ 
mum amount of donations. Once that 
level is reached, the creator promises to 
release the work into the public domain. 
After releasing the work, the third party 
transfers the donated money to the 
creator. 

After discussing some of the motivations 
that individuals would have to become 
donors, and the fact that the whole 
notion of IP is relatively new, Schneier 
opened the floor to questions. Perry 
Metzger suggested that this protocol/eco¬ 
nomic model would not result in the 
same volume of goods as the market can 
sustain, and pointed out that Penguin 
Classics makes money as a value-added 
reseller of works in the public domain. 
Max Tsvetovat inquired as to the applica¬ 
bility of this protocol to open source soft¬ 
ware; Schneier responded that the closest 
match would be to use proposed feature 
lists as the description of the “work.” 
Stuart Feldman then pointed out that 
Victorian subscription incorporated a 
very similar economic model, in which 
the contributors' names appeared on the 
first page of each work. Nicko Van 
Someren pointed out that widespread use 
of this protocol could result in IP pro¬ 
duction focusing on form rather than 
substance, and that production could 
change course back to forms, such as 
books, whose reproduction is more diffi¬ 
cult. Juan Garay asked whether it is a 
problem that the trusted third party will 
become quite large when dealing with 
works that are reviewed prior to publica¬ 
tion; Schneier responded that this already 
occurs. 
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VarietyCash: A Multi-purpose Electronic 
Payment System 

M. Bellare, University of California, 
San Diego; J. Garay, Bell 
Laboratories; C. Jutia, IBM TJ. 

Watson Research Center; M. Yung, 
CertCo 

Charanjit Juda presented the culmination 
of some six years of cooperative research 
by the authors into a form of digital cash 
intended to replace physical cash. They 
explicitly consider only the single-issuer 
situation, but assert that the scheme can 
easily be extended to multiple-issuer. The 
main problem addressed by their 
approach is the need to incorporate net¬ 
work-based (online) and smartcard based 
(offline) solutions in a single interopera¬ 
ble system. 

After discussing some other electronic 
payment schemes, and how they fare with 
regards to anonymity, atomicity, and net¬ 
work vs. smartcard issues, Jutia intro¬ 
duced the features of VarietyCash. These 
include an Issuer that maintains a list of 
all issued but unspent coins and a truly 
account-less system for ease of mainte¬ 
nance. The main cost of the system is 
incorporated in verification of each 
transaction. The Issuer in this system is 
trusted to preserve anonymity (which can 
be removed if required, e.g., by law). 

Some of the security goals addressed by 
VarietyCash are: protocol security, inter¬ 
nal security, user security, and network 
security. It uses tamper-proof hardware at 
the Issuer site to prevent insider attacks. 
Storing an encrypted version of each 
issued coin in a database at the issuer site 
is also required as a defense against insid¬ 
er attacks. The main goal in User Security 
is to prevent the loss of the user’s 
anonymity. 

Other features of the system include: 
using the issuer as a certification authori¬ 
ty, a global requirement for “conservation 
of cash.” Jutia also gave a brief trace 
through the Coin Purchase Protocol, 
emphasizing the speed of the Issuer in 


this protocol, and then showed the 
Payment Protocol at a high level. He said 
that a prototype system has been built, 
and that anyone interested in a demo 
should contact him. 

Raphael Yahalom asked about the differ¬ 
ence between anonymity in this system 
and the trust in credit card purchases; the 
answer was the receipt is the basis for the 
accountability in credit card purchases, 
and there’s no such receipt in this system. 
Nevin Heintze suggested that some 
requirements were missing from the for¬ 
malization, including guarantees of coin 
value and coin delivery upon purchase. 
Mark Seiden questioned the value of 
using VarietyCash versus a ledger-based 
system; the benefit is in the efficiency of 
the VarietyCash approach. Seiden also 
wanted to know what the result of an 
issuer private key breach is; the answer 
was that there is a large consequence to 
this, and the system is built to insure that 
the private key is kept private. An offline 
conversation with Jutia provided this 
more complete response: the Issuer has 
many keys - one for signing the coin, one 
for encrypting the coin in its database, 
one that is its public-private key pair for 
communications, one that is a public-pri¬ 
vate key pair for certificates. The system 
doesn’t break if any of these keys is lost. 

It may lead to small-scale attacks: for 
example, if the signing key is lost, it leads 
to insider attacks; if the database encryp¬ 
tion key is lost, again it may lead to insid¬ 
er or intruder attacks; if the communica¬ 
tion key is lost, it could lead to theft of 
users’ coins. 

NetCents: A Lightweight Protocol for 
Secure Micropayments 

Tomi Poutanen, University of Toronto; 
Heather Hinton, Ryerson University; 
Michael Stumm, University of Toronto 

Tomi Poutanen discussed NetCents, 
which was originally designed to be a 
micropayment protocol for use on the 
Internet. The protocol has since been 
extended to support a wider range of val¬ 


ues while maintaining efficiency and 
robustness. 

Part of the motivation for this work is the 
fact that credit cards are used as the pri¬ 
mary payment method on the Internet, 
even though their use includes several 
flaws. Poutanen listed the desired fea¬ 
tures in a payment protocol for the 
Internet. It must: be secure (by avoiding 
double-spending), be goods atomic, sup¬ 
port anonymity, and support a full range 
of values. Importantly, it must be imple- 
mentable; thus, it must be scalable, inter¬ 
operable, and low-cost. He also noted 
that to gain consumer support, it should 
be “as easy to use as real cash.” 

The design of NetCents considers the 
tradeoff between security and cost that is 
inherent in the online versus offline deci¬ 
sion. Its heritage is traced to Millicent, 
but it is more feature-rich, secure, and 
cheaper than Millicent. NetCents makes 
use of the public/private split in several 
ways, including separation of the scrip, 
and using public-key verification to verify 
each electronic payment order. 

Batching of payments in NetCents is used 
to increase efficiency and remove some 
load from the bank. This feature directly 
influences the need to be able to transfer 
scrip from one vendor to another; this is 
included as a sub-protocol of the pur¬ 
chase protocol. After describing these fea¬ 
tures, Poutanen discussed fraud control 
in their system. The protocol ensures that 
scrip transfers are atomic, and that 
though a criminal vendor can allow cus¬ 
tomers to double-spend, a probabilistic 
verification scheme makes it economical¬ 
ly undesirable to do. 

Poutanen then described how NetCents 
handles the crossover between online and 
offline protocols. Online arbitration is 
performed by means of a trusted third 
party, and the issuer maintains a certain 
minimal balance so that large purchases 
can go through while smaller balances are 
stored at vendors in support of cheap 
(offline) micropayments. The perfor¬ 
mance of an individual vendor depends 
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highly upon the scrip co-location hit per¬ 
formance. 

Bill Frantz wanted to know if the need 
for secure hardware at the issuer’s site 
indicated that we also need trusted code 
at each vendor’s site; the answer was that 
NetCents doesn’t require tamper proof 
hardware at each vendor, but only may 
catch cheaters. Manoj Kumar asked how 
to detect which of possibly many vendors 
in a scrip transfer chain was the mali¬ 
cious one; the answer was a full audit 
path is required to determine which was 
the malicious vendor. Kumar then point¬ 
ed out that this would require each ven¬ 
dor to keep track of all outbound scrip 
transfers each day (to be flushed when 
transferred to real monetary value). Tracy 
Mullen asked what happens when a ven¬ 
dor fails during a purchase; the answer 
was that the value is rolled back into the 
scrip, as if the purchase had not occurred. 

Session: Auction Markets 

Summary by Matthew Hohifeld 

The Auction Manager: Market 
Middleware for Large-Scale Electronic 
Commerce 

Tracy Mullen and Michael P. 

Wellman, University of Michigan 

To introduce the motivation for their 
work, Tracy Mullen described an ongoing 
project in which the University of 
Michigan Digital Library is modelled as 
an information economy. Within this 
environment, different types of organiza¬ 
tions have different market policies (e.g., 
corporate information policies vs. grade 
school ones). Participating individuals 
change over time and have needs that 
vary with current projects and interests. 
The authors’ work addresses how to build 
flexible infrastructures that can support 
such dynamic, diverse economies. Mullen 
described how formal description lan¬ 
guages for goods, services, and auctions 
(where auctions are really just services for 
setting a price) are used within their sys¬ 
tem interaction protocols and middle 


ware components to automate and sim¬ 
plify the electronic commerce process. 

The talk focused on a particular compo¬ 
nent, the Auction Manager, which gener¬ 
ates and tracks markets and provides 
other market management services. 
Commerce on the Internet often faces 
different economics than those of more 
traditional commerce channels, including 
lower transaction and distributions costs 
and marginal costs near zero for infor¬ 
mation goods, which tends to promote 
product bundling and unbundling. The 
Auction Manager must be able to match 
buyers and sellers in this more complex 
environment. 

By extending product descriptions to 
include bundling and unbundling opera¬ 
tors, Mullen showed how logical infer¬ 
ence rules could be used to locate appro¬ 
priate markets for buyers and sellers, as 
well as find potential arbitrage opportu¬ 
nities across related markets. In addition, 
the concept of buyer’s and seller’s choice 
bundling was introduced. Buyer’s choice 
means that instead of buyers buying an 
entire bundle of goods or services, they 
can buy the option to choose one or 
more of these products; seller’s choice is 
similar. For example, a newspaper is real¬ 
ly a bundle of articles sold as seller’s 
choice; this same bundle of articles could 
be sold as buyer’s choice, where the buy¬ 
ers decide which they want to read. 

In addition to matching agents with mar¬ 
kets, the Auction Manager also serves as 
the focal point for market creation and 
selection policies. Since infrastructure 
costs and agent decision complexity costs 
exist for each market created, unlimited 
market creation has the potential to over¬ 
whelm the system. The Auction Manager 
is being used to explore enforcing various 
market-creation policies, such as having 
explicit organizational policies or using 
auction fees to provide agents with the 
right incentives not to create unnecessary 
markets. 

Finally, the Auction Manager can also 
serv^e as a repository of market and orga¬ 


nization-specific knowledge about select¬ 
ing the best kinds of markets for 
exchanging different types of goods or 
services. While agents can always specify 
exactly the type of market they desire, 
they also have the option of allowing the 
Auction Manager to fill in reasonable 
defaults. Future work includes extending 
both the market creation and market 
selection policies. 

The only question came from Max 
Tsvetovat, who wanted to know if the 
Auction Manager is a central, trusted 
component of the system; the answer was 
that though it can be distributed, it is 
centralized and trusted for simplicity. 

Internet Auctions 

Manoj Kumar, Stuart I. Feldman, IBM 
T. J . Watson Research Center _ 

Manoj Kumar started his presentation 
with an anecdotal note about the history 
of auctions on the Internet: the most 
expensive T-shirt sold from the Nagano 
Olympics Web site in a series of daily 
sealed-bid auctions went for $15,000. He 
went on to present a list of the auction 
issues he would not be addressing: legal 
issues, cheating and/or sabotage, social 
issues, and multi-piece or continuous 
auctions. 

With all of that out of the way, Kumar 
launched into predictions about the 
future of auctions on the Internet. The 
authors believe that there will be an 
increase in the popularity of auctions for 
several reasons, including the integration 
of auctions with existing business 
processes and an increase in trust in the 
auction model. Kumar noted that though 
there are already many traditional uses of 
auctions in business-to-business transac¬ 
tions, there is room for new forms and 
uses of auctions in business-to-consumer 
transactions. 

Kumar then provided a classification of 
auctions and introduced some of the 
common variations on these types. He 
then introduced the system that the 
authors built on top of Net.Commerce 
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(an existing IBM product) to allow for 
the integrated use of auctions in busi¬ 
ness-to-consumer transactions. They 
built this in a consumer-oriented fashion 
and made it as close to fixed-price shop¬ 
ping as possible. By choosing to make 
this a consumer-oriented project, they 
became aware that the user interface is 
very important its success. Kumar then 
described the user interface and its simi¬ 
larities to the “shopping cart” metaphor 
in current Web sites. 

The Auctioneer is the commercial site in 
this setup, and the user interface for the 
Auctioneer has also undergone extensive 
work, including “experts” that provide 
pre-defined auction types. This is all built 
using a generic infrastructure that sup¬ 
ports a wide variety of auctions, a proto¬ 
type of which is available at 
<http://wvm.software.ibm.com/commerce/ 
net.commerce>. 

Doug Tygar expressed his concern about 
the ability of this model to address the 
latency of bids, especially in double auc¬ 
tions; Kumar acknowledged that this 
problem is currently being ignored by the 
system. Tygar was also curious about how 
“accidental” bids are prevented; the 
answer was that a registration mechanism 
helps to prevent this (a full description is 
in the paper). Giray Pultar then asked 
about the use of agents for bidding in 
this system; the answer was that agents 
aren’t yet allowed. 

Electronic Auctions with Private Bids 

Michael Harkavy and J. D. Tygar 
Carnegie Mellon University; Hiroaki 
Kikuchi^ Tokai University _ 

Michael Harkavy, winner of the work¬ 
shop’s Best Student Paper award for this 
work, began his presentation by skipping 
his prepared description of traditional 
auctions, since the previous two speakers 
had already thoroughly covered that 
topic. He then presented a double-bar¬ 
reled argument for the use of sealed-bid 
Vickrey auctions in an electronic setting: 


sealed-bid auctions are beneficial since 
they hide the preferences of the bidders, 
and Vickrey auctions have nice economic 
and efficiency properties. 

Harkavy then discussed some of the 
problems in situations where bidding 
preferences are leaked, including sig¬ 
nalling and cooperation between bidders. 
He claimed that simply having anony¬ 
mous bidding is insufficient to protect 
the privacy of a bid. 

Harkavy described how to leverage verifi¬ 
able secret sharing and secret computa¬ 
tion in order to implement an electronic 
auction that preserves the privacy of 
bids,. This includes addition and multi¬ 
plication on shared secrets, where the 
computation and the intermediate results 
do not reveal the secrets. Using this tech¬ 
nique, more complex functions (like the 
maximum function) can be computed on 
secrets. 

One restriction that the desire for effi¬ 
ciency forces on this system is the need to 
encode all bids into a given range. The 
bidders encode their bids into a secret 
that is distributed among auctioneers 
(where only t of the n auctioneers can be 
malicious). The auctioneers then com¬ 
pute the maximum function digit by 
digit on their inputs, eliminating bidders 
without revealing their bid or their iden¬ 
tity. The winning bidder is revealed at the 
end of the computation. 

Harkavy concluded his presentation by 
describing some of the lower-level details 
and optimization techniques used to 
attain some measure of efficiency. There 
is an inherent tradeoff in this system 
between the efficiency of the computa¬ 
tion and the security of the individual 
bids. 


Session: Secure Systems - 
What It Takes 

Summary by Kevin Fu 

A Resilient Access Control Scheme for 
Secure Electronic Transactions 

Jong-Hyeon Lee, University of 
Cambridge 

Jong-Hyeon Lee presented a way to 
authenticate customers without disclos¬ 
ing customer secrets to a merchant. (Lee, 
a student of Ross Anderson, is also capa¬ 
ble of security in another dimension - 
Aikido.) 

Despite the vulnerability to copying, 
passwords and Personal Identification 
Numbers (PINs) commonly authenticate 
customers to service providers. Lee 
sought a simple and secure electronic 
transaction model that does not have to 
explicitly transfer customer secrets and or 
use public key cryptography. A scheme by 
Needham to control PINs is simple, pro¬ 
vides for privacy, separates capabilities, 
and is customer-oriented; However, it is 
susceptible to replay attacks and bogus 
ATM machines. 

Inspired by Needham’s scheme, Lee 
developed a customer-oriented transac¬ 
tion model in which the customer gener¬ 
ates and maintains personal secrets. The 
model enables a transaction procedure 
among three principals: a customer, a 
merchant, and a bank. Principals can par¬ 
ticipate in registration, transaction, or 
secret-revocation procedures. A some¬ 
what lengthy protocol explains the com¬ 
munication among the principals. By 
using only hash functions, Lee’s model 
enhances privacy for the customer and 
ensures nonrepudiation. 

The registration procedure mimics that 
of Needham’s scheme, and the transac¬ 
tion procedure uses a technique from 
KryptoKnight. In Lee’s online scheme, 
the customer is involved with all proce¬ 
dures. An offline scheme works in a simi¬ 
lar manner, but there is some extra com- 
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munication between the merchant and 
customer. 

Asked whether there exists an implemen¬ 
tation, Lee explained there is yet no 
implementation for this scheme, but 
there is for Needham s scheme. 

See <http://www.cl.cam.ac.uk/Hhl21> for more 
information. 

Trusting Trusted Hardware: Towards a 
Formal Model for Programmable Secure 
Coprocessors 

Sean W. Smith and Vernon Austel, 

IBM T.J. Watson Research Center 

Sean Smith presented his findings on 
proving the security of secure coproces¬ 
sors with respect to Federal Information 
Processing Standard (FIPS) 140-1 level 4 
certification. His group worked on three 
goals: achieving level 4 certification as a 
research project, verifying the soundness 
or finding the holes in the coprocessor, 
and formally describing the coprocessor. 

FIPS 140-1 specifies security require¬ 
ments for cryptographic modules. The 
most stringent level in the standard, FIPS 
140-1 level 4, requires a formal model of 
a system and formal proof of security. As 
of this writing, level 4 is an unachieved 
grail. 

A secure coprocessor is hardware that 
must survive in a hostile environment. It 
must guarantee that memory contents 
will be zeroized upon any foreseeable 
attack, and it needs to defend against 
threats such as changes in voltage, tem¬ 
perature, and radiation. Such a program¬ 
mable device is useful for e-commerce. 

A mechanical theorem prover was iterat¬ 
ed over a logical abstraction of the 
coprocessor. First, a formal model was 
made from a finite state machine. Then a 
specification was written in LISP to prove 
simple properties of security. The proof 
must show that the coprocessor main¬ 
tains its security guarantees despite hard¬ 
ware failures and hardware attacks. 
Guarantees for security fall into three cat¬ 
egories: safe execution, safe access, and 


safe zeroization. Other assertions include 
authenticated execution, recoverability, 
and fault tolerance. The proof involves 
2000 lines of C, 75 execution states, and 
7500 lines of a mechanical proof. 

Right now, only the hardware and boot¬ 
strap are being submitted for level 4 cer¬ 
tification. IBM’s plans for actual certifica¬ 
tion are still undecided. In this research, 
IBM went through a lot of the legwork 
for the bootstrap layer as an exercise; 
Smith notes that it would be “really cool” 
to go all the way with it. In the future. 
Smith hopes to evaluate the programs on 
the coprocessor. However, he expects 
complications, since the hardware could 
interrupt the software and the software 
could start interrupting the software. 

Pointing out that FIPS is aging, an audi¬ 
ence member asked Smith to share hints 
on where FIPS is falling short and where 
it goes too far. Smith replied that on the 
too-stringent side, FIPS requires the use 
of DSA for signatures. Everyone wants to 
use RSA, but to be FIPS-compliant, the 
coprocessor must contain algorithms no 
one wants to use. On the other hand, 
FIPS does not address security require¬ 
ments of the manufacturing process. 

Another audience member brought up 
the topic of differential power analysis 
with current fluctuations. Many security 
attacks result from crossing levels of 
abstraction (power analysis, buffer over¬ 
run, etc). Smith was ambivalent on 
whether good proof techniques can cap¬ 
ture these attacks. 

For more information, see 
<http7/www.ibm.com/security/ciyptocards/> and 
the IBM 4758 product brochure G325- 
1118. 


On Secure and Pseudonymous Client- 
Relationships with Multiple Servers 

Daniel Bleichenbacher, Eran Gabber, 
Phil Gibbons, Yossi Matias, and Alain 
Mayer, Lucent Technologies, Bell 
Laboratories 


Alain Mayer talked about Janus, a crypto¬ 
graphic engine to establish and maintain 
pseudonymous relationships. Mayer 
enjoys hacking JavaScript and having fun 
on the Web. Coincidentally, he used the 
same Microsoft clip art in his presenta¬ 
tion as does the Crowds project. 


Janus facilitates relative pseudonymity. 
That is, a client is anonymous with 
respect to the client population (e.g., an 
ISP customer base). The server knows a 
message came from a particular client 
population, but it does not know which 
member of the population. Janus also 
allows for persistent relationships 
between clients and servers. Weak or 
strong authentication by means of pass¬ 
words or keys allows for repeat visits. 

Absolute anonymity is hard to achieve 
without a penalty in ease of use and 
performance. The work on Janus is 
complementary to other anonymizing 
efforts and can be combined with other 
techniques. 

There is a distinction between data 
anonymity and connection anonymity. In 
data anonymity, data flowing over a con¬ 
nection does not reveal an identity. In 
this case the adversary would attack serv¬ 
er endpoints. In connection anonymity, 
the connection itself does not reveal an 
identity, and the vulnerability is traffic 
analysis. 

There are several candidate Janus func¬ 
tions. Mayer has three requirements of 
the function. First, it must ensure 
uniqueness of aliases among clients and 
resist impersonation; in other words, it 
must be hard to find an input that results 
in the same alias. Second, the function 
must not reveal information about 
clients. Third, there must be forward 
secrecy and statelessness for client mobil- 
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ity. Mayer described one such function 
involving a password-keyed hash of a 
client identifier, server identifier, and a 
usage tag. Mayer finds the CBC-MAC 
approach more promising than a simple 
hash because secrecy under a chosen 
message attack implies secrecy of pass¬ 
words. The CBC-MAC approach fulfills 
all three requirements. 

Janus works with email aliases. Aliased 
email can also help filter junk mail. A 
client may have a different mailbox for 
each server. One can filter (even by a 
third party) by ignoring mail to a partic¬ 
ular alias. 

Mayer indicated several places to house a 
Janus engine. In a local approach, the 
Janus engine lives in the client. Aliases 
would be routed through a proxy. This 
minimizes outside trust and cooperates 
with mobile code and Personal Privacy 
Preferences (P3P) repositories. In a gate¬ 
way approach, a client need not down¬ 
load software. This allows easy upgrades 
and maintenance. In a third party 
approach, the Janus engine would exist in 
the outside world. The third party pre¬ 
serves subnet anonymity. Mayer pointed 
out that if you look at a gateway or local 
approach, the domain name or IP 
address does not reveal its alias or real 
address. A vendor could ask for a credit 
card for identity validation. 

An audience participant asked whether 
anonymity is really beyond research and 
useful in the real world. Mayer responded 
that according to surveys on electronic 
commerce, end users worry about priva¬ 
cy. A high percentage of users leave sites 
that present fill-out forms. To demon¬ 
strate practicality, Mayer offered the 
example of personalized Web pages. A 
user no longer must remember pass¬ 
words for services such as My Yahoo or 
NYT. Janus can be a tool to make person¬ 
alized sites as easy to visit as regular sites. 

The Lucent Personalized Web Assistant 
uses a Janus engine. See 
<http://lpwa.coni:8000/> for more information. 


Secure WWW Transactions Using 
Standard HTTP and Java Applets 

F. Bergadano, Universita di Torino, 
Italy; B. Crispo, University of 
Cambridge and Universita di Torino; 

M. Eccettuato, Universita di Torino. 

Francesco Bergadano presented an alter¬ 
native for securing HTTP transactions. 
This solution uses local Java applets on 
the client side to establish a secure link 
with the server. 

Existing solutions include modifications 
to the application protocol (e.g., 

ShTTP), a secure transport below the 
browser (e.g., SSL/TLS, DCE-Web trans¬ 
port APIs), proxy-based services, and 
network layer changes (e.g., IPsec). 
Bergadano’s group wanted to achieve pri¬ 
vacy, authentication, and possibly non¬ 
repudiation. However, they did not want 
to implement a new browser or modify 
existing browsers. Moreover, they wanted 
to provide strong cryptography and make 
the source code freely available. 

The proposed architecture uses normal 
HTTP, TCP, and a Java-capable browser. 
Essentially, the client runs an applet from 
the server. This applet triggers a local 
applet that communicates with a local 
application on the client. This application 
in turn creates an encrypted channel with 
the server. 

This approach requires relatively few 
changes. More important, Bergadano 
claims it does not require trust of the 
browser. It is desirable to separate securi¬ 
ty routines from the browser. This 
approach is similar to a proxy-based 
approach. However, a proxy must inter¬ 
vene with all communication. 

Bergadano’s approach only becomes 
active when an HTTP transaction is 
explicitly asked to be secure. 

Launching several questions, Avi Rubin 
asked Bergadano to answer just one: 
Where did you put security? Is it better 
than SSL, why can t you run a simple 
proxy? Are you assuming you can change 


a firewall configuration? Taking a deep 
breath, Bergadano jokingly asked when 
dinner was scheduled. He chose to 
answer the SSL and firewall questions. In 
the case of SSL, one needs a trusted 
browser that supports SSL. In Europe, 
one cannot easily obtain a standard 
browser with strong cryptography. As for 
the firewall, Bergadano reported that the 
implementation was run on an open net¬ 
work. He was unsure about interactions 
with a firewall since a secondary channel 
must be established between the client 
and server. Another attendee commented 
that if this approach gets well used and 
works, it would be consumed by a 
browser. 

For more information and the source 
code, see <http://security.unlto.it/>. 

SWAPEROO: A Simple Wallet 
Architecture for Payments, Exchanges, 
Refunds, and Other Operations 

Neil Daswani, Dan Boneh, Hector 
Garcia-Molina, Steven Ketchpel, and 
Andreas Paepcke, Stanford University 

Neil Daswani presented the SWAPEROO 
digital wallet project. Started in 
September 1997, this project aimed to 
identify desirable wallet properties and 
features, define a wallet interaction 
model, define clean APIs for a wallet and 
its components, and build a prototype. 

Daswani’s group decided that: (1) A wal¬ 
let architecture should be extensible. 
Rather than being completely propri¬ 
etary, it should support multiple instru¬ 
ments and protocols. (2) It should not 
rely on a Web interface as the sole com¬ 
mon interface. The basic architecture 
should be written once to be run any¬ 
where. This enables the use of alternative 
devices such as Personal Digital Assistants 
(PDAs). (3) Symmetry allows for com¬ 
mon services across commerce applica¬ 
tions. Current wallet implementations are 
often non-symmetric; little infrastructure 
is shared between the client and server 
sides. (4) A wallet architecture should be 
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client-driven. The user should initiate all 
transactions. Vendors should not be 
capable of automatically invoking a 
client’s digital wallet. After all, would you 
want a vendor reaching for your wallet as 
soon as you enter a store? 

Daswani described a wallet interaction 
model. After starting a transaction, wal¬ 
lets can negotiate on a protocol. Because 
of symmetry, the user and vendor have 
similar wallets. 

SWAPEROO has been implemented in 
C++ (PalmOS) and Java (Windows). 
Future work includes populating the wal¬ 
let, experimenting with other devices 
(e.g., smart cards), working on the archi¬ 
tecture, and abstracting out the data 
manager. 

One question was asked about symmetry. 
Since everyone would have wallets of a 
similar design, is there any reason clients 
would not want to communicate with 
each other? Daswani responded that 
there are no restrictions. Another ques¬ 
tion involved tamper resistance. Given 
that the wallet must be in some tamper 
resistant memory, how are these things 
initialized? Daswani answered that for 
PalmPilots, this is a problem. However, in 
the future with a JVM access control, a 
policy could potentially be downloaded 
directly into the wallet from a trusted 
site. 

A related paper on the PalmPilot imple¬ 
mentation will appear in the future. The 
PalmPilot implementation lets a user buy 
a food item from a particular vending 
machine at Stanford. For more informa¬ 
tion, see <http://www-db.stanford.edu/ 
~daswani/wallets/> 

The Eternal Resource Locator: An 
Alternative Means of Establishing Trust 
on the World Wide Web 

Ross Anderson, Vaclav Matyas, and 
Fabien A.P. Petitcolas, University of 
Cambridge 

Vaclav Matyas presented an alternative 
means of managing trust in electronic 


publishing. He spoke about WAX, a pro¬ 
prietary hypertext system for medical 
publishing. WAX uses hashes in combi¬ 
nation with HTML links as an Eternal 
Resource Locator (ERL). Matyas is also 
the co-editor of the Global Trust Register, 
a massive directory with its own rating 
scheme of “top-level” PGP keys and 
X.509 certificates. 

In the hierarchical WAX system, there are 
shelves owned by publishers, books 
owned by editors, and chapters owned 
by authors. WAX must protect against 
several threats: book contents could be 
altered, an incorrect book source could 
be claimed, or a publisher or author 
could deny past content. Matyas stressed 
that there are no confidentiality or 
audit requirements, only integrity and 
authenticity. 

The WAX system originally used RSA for 
digital signatures. However, problems 
cropped up. In particular, RSA digital 
signatures require a Public Key 
Infrastructure (PKI), expiring keys cause 
problems for long-lasting information, 
compromised keys are difficult to 
address, and RSA-DSI royalties were 
expensive. As a result, WAX uses one¬ 
time signatures as an intermediate 
solution. 

New HTML elements allow hashes and 
public keys to be embedded in docu¬ 
ments. In addition to the standard link¬ 
ing information, the A element also 
includes a HASHVALUE parameter. 
When a browser follows a link, it can 
hash the appropriate contents and verify 
whether the document is authentic. For 
instance, a link may appear as <a 
HREF=''http: //www.med.ac.uk/ 
exainresults ” HASHMETHOD= ”TIGER" 
HASHVALUE="12345..." 

HASHPARENT= "http: //www.cert .med, 
ac .uk">link</a>. The exam results 
page would contain further information 
to reconstruct the hash. 

Pure ERLs apply easily to static texts (e.g., 
health care, law and contracting, bank¬ 
ing). One can also store hashes with 


bookmarks for change control. 
Additionally, this system can interact 
with public key mechanisms. Work pro¬ 
gresses on medical applications (WAX, 
British National Formulary), incorpora¬ 
tion of XML discussed with industrial 
partners, and formalization of the ERL 
logic extended by public key parameters. 

For more information, email 
<vm206@cl.cam.ac.uk> or visit 
<http://www.cLcam.ac.uk/~fapp2/papers 
/ec98-erl/> and 

<http://www.medinfo.cam.ac.uk/wax/>. 

Detecting Hit Shaving in Click-Through 
Payment Schemes 

Michael Reiter, AT&T Labs - 
Research; Vinod Anupam and Alain 
Mayer, Lucent Technologies, Bell 
Laboratories 

Mike Reiter, presenting the winner of the 
workshop’s Best Paper award, analyzed 
several mechanisms to calculate upper 
and lower bounds on referrals to another 
Web site. This is particularly useful in 
Web advertising schemes where a Web 
publisher receives a payment directly 
proportional to the number of “click¬ 
throughs” generated, 

A user U “clicks through” site A to site B 
if A serves a page to U, and then U clicks 
on a link in A’s page to reach B. Here A is 
the referrer and B is the target. In a click¬ 
through payment scheme, B pays A for 
each referral that A gives to B. There are 
two common forms of fraud in click¬ 
through payment schemes. Hit shaving 
results when site B fails to credit site A 
for referrals. Hit inflation results when 
site A causes bogus referrals to site B. 

Reiter described two classes of practical 
and immediately useful techniques for 
detecting hit shaving. In a heuristic 
approach, the target site need not cooper¬ 
ate or even have knowledge of the 
process. In a cooperative approach, one 
can achieve better accuracy and non¬ 
repudiation of click-throughs. For both 
classes, the detection techniques are 
mostly invisible to the user. 
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The detection process must enable site A 
to monitor how often site B receives a 
request from any user U with a referrer 
field indicating A. This leads to the ques¬ 
tion of how to calculate upper and lower 
bounds on hit counts. Site A can record 
an upper bound on its referrals to site B 
with no cooperation from B. When user 
U clicks on a link to site B, A is told 
about the click. Then user U continues to 
B. One can implement this using HTTP 
redirection or a CGI script. A second 
approach uses JavaScript and an invisible 
frame to notify site A of the intent to fol¬ 
low a link. These techniques produce an 
upper bound because one cannot be sure 
whether B actually receives the hit. The 
notification represents the intention to 
visit site B, but not a guarantee to visit 
site B. 

Techniques to calculate a lower bound are 
not so clean or simple. After a user fol¬ 
lows the link on site A to reach site B, the 
user notifies site A. A receives notification 
only if the connection to B worked. 

Reiter described a rather complicated 
procedure which spawned a new browser 
window and used JavaScript. Since one 
window cannot access another window’s 
namespace, there are a few hoops to 
jump through. A detection window 
probes the namespace of the window 
attempting to contact site B. When the 
detection window is no longer allowed to 
probe the other window, it knows the 
connection to site B was successful. The 
detection window then notifies site A by 
requesting a particular URL. 

The lower bound technique has a few 
caveats. The user might close the window 
before A is notified. Additionally, this 
only detects that some page is loaded. 

The user may have stopped the request to 
site B and traveled elsewhere. A few tricks 
(e.g., hiding the toolbar) can make it 
hard for the user to bypass the notifica¬ 
tion process, but it also can cause annoy¬ 
ances to the user. 

Reiter suggests using both lower and 
upper bound detection on referrals. The 


two measurements should be fairly 
similar. 

In the cooperative approaches, site B 
acknowledges each referral as the referral 
happens. In a naive solution, B would 
open a connection to A for each hit. In a 
distributed approach, B’s page would 
make the user request another page from 
site A as an acknowledgment. It is also 
possible to provide for nonrepudiation 
with digital signatures. B includes a 
digital signature while serving a page. 
However, this could easily become pro¬ 
hibitively costly. Hash chaining can alle¬ 
viate some of the performance problems. 

Reiter revealed a few disadvantages of hit 
shaving detection. There is a negative 
impact on user privacy. Web sites can dis¬ 
cover your browsing habits. The schemes 
are also incompatible with anonymizing 
services such as Crowds or LPWA. 

Questions began on a humorous note. 
How did Reiter become involved with 
this project? The saga began when Reiter 
placed his email address on a Web page. 

A spammer sent an email about click¬ 
through payments saying that a 1998 
Corvette would be awarded for the high¬ 
est number of click-throughs. Thinking 
something must be fishy, Reiter began to 
analyze click-through payment schemes. 
A few questions about ethics and morali¬ 
ty popped up. All concerned impedi¬ 
ments to the user (e.g., awkward win¬ 
dows popping up) and pornography. 
Reiter cleverly escaped the questions with 
witty remarks. However, he made it clear 
that improving the porn industry is not 
his goal. Click-through payment schemes 
are relevant for all types of Web advertis¬ 
ing. Finally one attendee pointed out that 
these schemes act like a poor man’s 
Remote Procedure Call via URLs. Asked 
whether he was on to something bigger, 
Reiter replied that there might be overlap 
or some related opportunities. 


Session: Consumer Service 

Summary by Matthew Hohifeld 

Sales Promotions on the Internet 

Manoj Kumar, Anand Rangachari, 
Anant Jhingran and Rakesh Mohan, 
IBM TJ. Watson Research Center 

Manoj Kumar presented his group’s work 
on translating another set of real-world 
practices to the world of electronic com¬ 
merce. Their specific goal is to provide 
the types of sales promotions that are not 
currently available at commerce sites on 
the Internet, namely coupons. 

Kumar gave a list of fictional examples to 
illustrate the variety of purposes that can 
be addressed by coupons, and introduced 
the concept of eCoupons. The Internet 
disrupts several real-world assumptions 
and also allows some things that are not 
possible in the real world. One of the 
economic forces created by coupons is 
price discrimination. Price discrimina¬ 
tion does not follow the understood rules 
on the Internet, however, if coupon 
“trading” is allowed to be as simple as it 
would appear to be. 

One unexpected feature of coupons in 
the real world that issuers rely on is that 
they are “hard” to use. If the straightfor¬ 
ward methods for creating coupons are 
used in the setting of electronic com¬ 
merce, with the expected simple user 
interface, that would no longer be true. 
Kumar surprised me by discussing simi¬ 
larities between eCoupons and digital 
cash systems with respect to susceptibility 
to fraud, without stating that eCoupons 
are a type of digital cash (with a more 
complex “value” associated). 

eCoupons are a set of definitions that are 
being refined and extended to attempt to 
cover all possible variations on promo¬ 
tions desirable on the Internet. Kumar’s 
group is also investigating different meth¬ 
ods for delivery of coupons and methods 
for storage after delivery (such as digital 
cash “wallets”). 
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Perry Metzger stated that he thought that 
the marketing analysis in the presentation 
was better than the technical analysis, and 
that affinity schemes seem to be doing 
most of what is presented as eCoupons; 
many of the ideas are similar, just broad¬ 
er in scope. Avi Rubin wondered why 
eCoupons are needed when immediate 
discounts have all of the needed features 
listed; the only response was that busi¬ 
nesses seem to want to continue to use 
what they “know.” Max Tsvetovat suggest¬ 
ed that the use of auctions and other 
variable or negotiated prices is common 
and handles most of these needs; the 
response was that they solve orthogonal 
problems. 

General-purpose Digital Ticket 
Framework 

Ko Fujimura and Yoshiaki Nakajima, 
NTT Information and Communication 
Systems Labs 

Ko Fujimura presented a flexible digital 
ticket project whose main purpose is to 
develop a generic value-circulation medi¬ 
um that prevents double-spending. In 
this context, a ticket is a digital medium 
that guarantees certain rights to the 
owner of the ticket. Describing tickets 
this generally allows the tickets to contain 
many different values and types of values 
in a single ticket (or group thereof). 

Fujimura claims that a general ticket 
framework will reduce the implementa¬ 
tion cost in many cases because a single 
design can be used in many places. By 
being general, the tickets can be com¬ 
posed arbitrarily, allowing bundling and 
similar features. He claims that the cre¬ 
ation of new businesses to run this 
framework, like issuing/revocation ser¬ 
vices and deposit box services, was a 
benefit. 

A general-purpose digital ticket frame¬ 
work must meet most of the require¬ 
ments of digital cash. Additional require¬ 
ments are: (1) A ticket can control its 
anonymity, divisibility, and transferability 
depending on the application; (2) The 


individual specifications of a ticket need 
to be “machine understandable” to allow 
for the redemption of goods or services; 
(3) Ticket properties whose values change 
while it is circulated (e.g., payment or 
reservation status) must be changed 
securely; (4) A ticket that comprises more 
than one sub-tickets must be supported. 

To implement such a framework, the 
authors created a Ticket Definition 
Language that allows for the specification 
of ticket properties. The tickets them¬ 
selves are hypertext-based, allowing 
automation of the state-transitions and 
composability features. The tickets can 
also include dynamic information that is 
up-to-date when the ticket itself is used. 
Another feature (of less obvious utility) is 
that the tickets can contain very large 
data such as images and sounds. 

The tickets themselves are inherently 
online (because of their hypertext basis 
and dynamic nature), but can also be cir¬ 
culated offline using smartcards. In either 
case, the system uses signed URIs to test 
the currency of the ticket. The meaning 
and constraints of the properties in the 
tickets are defined using the Resource 
Description Framework. Schemas for 
tickets can thus be controlled by the 
issuers of the tickets, and various restric¬ 
tions can be contained in these schemas. 

Fujimura outlined the ticket trust model. 
The issuer certificate, user certificate, and 
examiner certificate, which are required 
to issue, transfer, consume, or examine a 
ticket, are specified in the ticket itself 
using the Ticket Definition Language. So, 
any ticket with PK, such as drivers’ licens¬ 
es, can be used as a PK certificate if a 
ticket specifies them as a required certifi¬ 
cate for the ticket. In other words, any 
ticket can play a roll in the PKI for other 
tickets. 

They are drafting specifications for the 
implementation and intend to submit 
them to standards organizations. The 
goal of their project is to “Transform any 
Web terminal into a ticketing machine 
for any ticket in the world.” 


Paul Syverson spoke from the audience to 
indicate briefly that many related issues 
and solutions were addressed by 
Unlinkable Service Transactions. 

Towards a Framework for Handling 
Disputes in Payment Systems 

N. Asokan, Els Van Herreweghen, 
Michael Steiner, IBM Research 
Laboratory 

Els Van Herreweghen spoke about dis¬ 
pute handling in a digital marketplace. 
While it is assumed in many designs that 
some offline dispute arbitration system 
exists, the designs do not include specifi¬ 
cations for addressing this. Systems need 
to obtain evidence in order to resolve dis¬ 
putes, to show exactly what the evidence 
means, and to provide tools for the 
analysis of this evidence (inside and out¬ 
side of arbitration). This evidence may be 
useful in situations other than litigation, 
such as local verification, friendly settle¬ 
ment, or showing a receipt to a third 
party. It should be possible to leverage 
the high-level interface of E-Commerce 
applications to address possible after-the- 
fact disputes. Van Herreweghen proceed¬ 
ed to give some clear examples what sorts 
of disputes these might be. 

She introduced a language for dispute 
claims in first-order logic with who, 
what, modifiers, and attributes. All possi¬ 
ble disputes in a given digital market sys¬ 
tem should be describable in this type of 
language. By representing protocols as a 
sequence of states where players in the 
protocol cause transitions between these 
states, she showed that a properly pro¬ 
duced transcript of the protocol would 
provide evidence for claims. A claim veri¬ 
fier can take such evidence to determine 
which states the protocol reached, and 
use knowledge of what those states 
“mean” in the protocol to determine 
whether or not the claim is valid. 

To provide proof that this method will 
work for automatic dispute handling, the 
authors are working toward building 
implementations for iKP and SET. They 
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suggest a three-party dispute resolution 
system in which the verifier interacts with 
the claimant and the respondent, accept¬ 
ing evidence and making a decision based 
upon the claim and the evidence. Van 
Herreweghen admitted that different sce¬ 
narios will require the use of different 
parties in the arbitration, and gave a brief 
overview of how to add dispute handling 
capabilities to a given payment system. 

Max Tsvetovat wanted to know about the 
applicability of this work to level com¬ 
mitment contract systems (contractual 
protocols); Van Herreweghen answered 
that if the claims and contracts are 
expressed correctly, these techniques 
should work. Paul Syverson asked where 
the formalism that is used originated 
from; the answer was that the authors 
were inspired by generic payment system 
interfaces, but there were no existing 
generic payment system-independent 
claim languages, so they developed a new 
language for payment disputes. Syverson 
also wanted to know about the overlap 
between this and other provable logic 
systems; the answer was that they want a 
usable system, and an unused/unusable 
formulation. (According to a later discus¬ 
sion with the speaker, the focus of their 
work has been mainly on the generic 
claim language and framework for pay¬ 
ment disputes. They were concerned pri¬ 
marily about the usability of their 
approach to existing, nonideal payment 
systems. They are involved in research 
into using other approaches and other 
logics for dispute resolution systems.) 


Session: Short Tolks/Works-in- 
Progress Reports (WIPs) 

Summary by Matthew Hohifeld 

Robert Hettinga is working on a full flow 
diagram of commerce in “Cypherspace” 
(or encrypted Cyberspace). He claimed 
that one of the most important features 
is a peer-to-peer design, allowing anyone 
in the system to play the role of “mer¬ 
chant” or “purchaser.” A white paper and 
the completed diagram will be forthcom¬ 
ing and available on his Web site. 

John de Pre Gauntt presented a non-US- 
central point of view on electronic 
commerce. He pointed out that market 
penetration of mobile phones is much 
higher than that of personal computers 
in other parts of the world, and proceed¬ 
ed to show how they could be (and are 
being) used as a vehicle for electronic 
commerce. 

Vinod Anupam suggested that even 
though there are many well-known 
attacks against the implementation of 
JavaScript in currently available commer¬ 
cial browsers, it is possible to fix this 
problem in coming versions. His group 
has been working on an implementation 
that uses a Safe Interpreter with control¬ 
lable security policies by building on the 
source code provided for Mozilla. They 
are attempting to get this feature rolled 
into the official Mozilla 5.0 when it is 
released. 

Otto Koppius presented the audience with 
a possible view of how multidimensional 
auctions could work. He noted that the 
auction itself will be dependent upon the 


evaluation function of the individual sell¬ 
ing the item. Koppius is currently 
involved in examining what will occur 
with different scenarios that are made 
possible by multidimensional auctions. 

Max Tsvetovat is looking at the issues 
involved in using agents to negotiate and 
execute contracts. The situations that his 
group is considering include multiple- 
supplier, single-customer arrangements. 
They are looking at a “one-shot, leveled- 
commitment” protocol to perform the 
negotiation, as well as other new topics. 

Bob Carter described his company’s 
efforts in deploying smartcards in a 
closed public key infrastructure in the 
context of delivering smartcards to 
account holders for a bank. 
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news & features 


[ Coming up to Speed ] 

by Tina Darmohray 

Tina Darmohray. editor of 
SAGE News & Features, is a 
consultant in the area of 
Internet firewalls and net¬ 
work connections, and fre¬ 
quently gives tutorials on 
those subjects. She was a 
founding member of SAGE. 

<tmd@usenix.org> 


iVe been a UNIX system administrator 
for 15 years. That number isn’t really 
accurate, however. I’ve been employed as 
a system administrator that long, but it’s 
probably a stretch to claim that I’ve been 
a fully functional sysadmin the entire 
time. Like so many system administra¬ 
tors, I learned just about everything 1 
know about system administration while 
on the job. So, while I was first hired in 
1983,1 probably wasn’t worth a signifi¬ 
cant part of my salary for a good bit of 
time after that. 

Luckily, I wasn’t alone. Many of the 
employees on the project were also learn¬ 
ing on the job. In fact, a small number of 
the more senior staff members readily 
admitted that they were there solely to 
learn about UNIX. They had come from 
years in the mainframe world and wanted 
to get some experience with the “new” 
operating system. They’d been working 
for years by then, and it showed. They 
were already senior system administrators 
and programmers. They knew about 
compilers, revision control systems, 
report generators, network stacks, system 
backups, IP addresses, disk drives, and all 
the rest of the standard computer fare. 

For the most part, they weren’t learning 
new concepts; they were just applying 
what they already knew to a different 
environment and learning how to “do it 
in UNIX.” They were coming up to speed 
with the “new” operating system. 


Now 1 find myself in a similar situation. 
While I’ll possibly never approach the 
competence of some of the senior staff 
members on that project. I’m no longer 
just learning my trade. 1 have a lot of 
experience to draw on now. lust as they 
were then, given a completely new OS 
environment. I’m still much farther 
ahead than someone just starting with his 
or her first one. I’m coming up to speed 
with NT. 

Since it worked last time. I’m approach¬ 
ing this learning curve in the same way I 
did with UNIX. I’ve got some machines 
to play with. I’ve bought books. I’m read¬ 
ing articles and online information, and 
I’m talking with peers. In general, I like to 
learn, so I’ve been enjoying the opportu¬ 
nity to really delve into something new. 
Sadly, it all came to an abrupt stop a few 
weeks ago when I was pretty far down the 
path to understanding the NT authenti¬ 
cation process and then hit a barrier. It 
was a Microsoft proprietary algorithm. 
Here I am, trying to educate myself so 1 
can get better at NT, and I get to a point 
where 1 can’t have an answer! It prompt¬ 
ed me to think about how one “gets good 
at” something, which took me back to my 
first system administration job and how 
we all learned about UNIX. With UNIX, 
if you want to know something, you can 
buy books, talk to coworkers, read 
USENET (prior to the Web), attend tuto¬ 
rials, and, if you have the determination, 
you can finally resort to printing out the 
source code and figuring it out! Granted, 
you may wind up learning more than you 
ever needed to know, but ultimately that’s 
your call, not someone else’s, to make. 

Somewhat deflated, 1 wondered if it was 
“just me.” So, over the past several weeks, 
I’ve been polling people that I talk to see 
if they’ve had a similar experience or per¬ 
ception with NT. To a person, they have. 
Not all of them were bothered by it, but 
all of them agreed that, in some respects, 
your hands are tied from becoming an 
“expert” (in the traditional source-code¬ 
level “UNIX-guru” sense) with NT. 


Remarkably, I also ran into a related busi¬ 
ness article that said that some large 
companies were, surprisingly, choosing 
Linux over NT, even though it’s not sup¬ 
ported. Apparently, the reason is because 
companies want to be assured they have 
control over fixes, which isn’t guaranteed 
when Microsoft “owns” the operating sys¬ 
tem. That makes sense to me, too, but I 
wouldn’t have predicted it. 

So, I’m left to wonder what this means 
for the level of expertise of NT system 
administrators. On one hand, my ele¬ 
mentary school kids can use the popular 
word processing package on NT, almost 
intuitively (and, realistically, that’s never 
going to happen with “vi”). From a sys¬ 
tem/network administrator perspective, 
however. I’m feeling a little like I’m left at 
the GUI level too. The high-level, and 
sometimes proprietary, NT interface to 
the system may mean that the NT 
“gurus” of the future have to settle for a 
more abstract level of knowledge than 
the UNIX gurus. I suppose we’ve lived 
with this knowledge restriction before, as 
in the days of OSes like MVS and VMS, 
but I’m not sure it’s as much fun. 
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[ End of Year Report ] 


by Hal Miller 

Hal Miller is president of the SAGE STG Executive 
Committee. 


<halm@usenix.org> 


It's been more than a year since I gave 
what probably should become an annual 
status report, so here is the State of 
SAGE, a summary of what we have been 
doing over the last couple of years. 


SAGE once operated on a series of 
“understandings.” That worked reason¬ 
ably well as long as the same people 
stayed on in all the relevant positions. 
Once those people moved on, the corpo¬ 
rate history left with them, and those 
who followed spent a considerable 
amount of time trying to recreate the 
“rules” under which SAGE operates. To 
fix this permanently, we wrote SAGE s 
first set of “articles of organization” and 
an accompanying policy documents. 
Included in these are a rewritten charter, 
a mission statement, and various changes 
such as the synchronization of elections. 

USENIX and SAGE hired a Webmaster. 
The SAGE Web site has grown tremen¬ 
dously, with lots of new items that go 
toward fulfilling the vision of SAGE. 
Some examples are the Code of Ethics, 
Speakers Bureau,ToolKit, Rosetta Stone, 


How-To Notes, Web Resources for NT. 

An editor was hired for the Short Topics 
Series. That series was itself rather short: 
there was only one entry when I was first 
elected to the executive committee. By 
the time you read this you should have 
four booklets on your shelf, and a fifth is 
due shortly. Others are in the pipeline. 

In addition to an ever-growing LISA, we 
now co-sponsor LISA-NT and the new 
network admins conference. This year's 
LISA includes a new workshop entitled 
“globalLISA,” as LISA continues branch¬ 
ing out to explore more problem areas 
faced by our members. We are investigat¬ 
ing similar expansion for Samba and 
other areas. 

We conducted surveys to see what you 
want from SAGE (and found exactly the 
diversity of opinion we expected). One 
area the surveying pointed out was your 
desired involvement in the standards 
process, so under Nick Stoughton's 
watchful eyes I gave a two-hour talk to a 
program committee of The Open Group 
about areas in which standards could 
help working sysadmins. We are looking 
at ways of continuing representation to 
this committee. 

Together with USENIX, we initiated an 
area we call “Good Works,” in which a 
Virtual High School session in Maryland 
was sponsored to teach students the 
basics of system administration.We are 


now looking at ways to make expanded 
use of the resulting curriculum, as well as 
at additional projects in a similar vein. 

Our membership numbers, and our con¬ 
tacts with sysadmin groups outside the 
US continue to grow. There are a bunch 
of new local groups, who have SAGE- 
sponsored speakers from time to time. 

We have an email-based pilot “mentor¬ 
ing” program in which one can go for 
individual question help (the “SAGE 
Oracle,” coming soon.) And then there's 
the “Day In The Life” survey and a SAGE 
History compilation. 

So what next? Here are four questions 
this organization needs to contemplate as 
we move forward. 

What should SAGE foe? This seems to me 
the real key question for the future. 
According to our charter, vision, and mis¬ 
sion statement (see <http://www.usenix. 
org/sage/official/official.html>) SAGE is a 
“professional guild.” It is “a membership 
group of system administrators organized 
to further, foster and recognize the pro¬ 
fession.” The role transcends operating 
system types, vendors, and locations. The 
purpose is to provide benefit to system 
administrators in their training, work¬ 
place environment, career advancement, 
and as a “place” a member can go for 
assistance. We are a primary point of 
contact for vendors - who else represents 
the people they actually want to sell to? 


SAGE, the System Administrators Guild, is a 
Special Technical Group within USENIX. It is 
organized to advance the status of computer 
system administration as a profession, 
establish standards of professional excellence 
and recognize those who attain them, develop 
guidelines for improving the technical and 
managerial capabilities of members of the 
profession, and promote activities that advance 
the state of the art or the community. 

To achieve its mission SAGE may: 

Sponsor technical conferences and workshops; 

Publish a newsletter, and/or professional 
short topics series; 


Develop curriculum recommendations and 
support education endeavors; 

Develop a process for the certification of 
professional system administrators; 

Recognize system administrators who are 
outstanding or are otherwise deserving of 
recognition for service to the professional 
community; 

Speak for the concerns of members to the 
media and make public statements on issues 
related to system administration; 

Promote and support the creation and activities 
of regional or local professional system 
administrators. 


SAGE STG EXECUTIVE COAAAAITTEE 
President: 

Hal Miller <halm@usenlx.org> 

Secretary: 
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We are neither a union, a guild, a trade, 
or a craft. We are not likely ever to be an 
industry-controlling agency like the 
national medical and legal associations, 
although we gain insight from parts of 
their positions and methods. We are a 
loose organization of diverse folks who 
have much in common, and are mutually 
supportive. 

In view of this, what should SAGE look 
like? Not very different from what we 
already are, but there are some adjust¬ 
ments rd like to see. SAGE in the US is a 
solid, alive, functioning organization. We 
have a central national directive body, 
financial backing, local groups, and a set 
of rules to play by. We still have problems 
in two areas: delegation and internation¬ 
alization. 

As with any volunteer group, we have a 
problem with delegation. Most of the 
work at any one time is done by a few 
people, despite lots of interest, lots of 
good intentions, and lots of promises to 
accomplish specific goals. SAGE has 
made a number of attempts to delegate 
work to more people, but we’re still 
floundering around trying to find a 
method that will work. Lots of us sign on 
for specific tasks in the enthusiasm of the 
moment only to find that our families 
and hectic work lives take precedence 
over volunteer work. Thus, most of the 
work of keeping SAGE going falls on the 


shoulders of a minority of the executive 
committee. Somehow, we need to involve 
more of our membership in the work we 
all think needs doing. 

We also need to remember that we need 
to look beyond our American system 
administration community, and coordi¬ 
nate better with our colleagues abroad. 
We all have the same problems, solutions, 
and needs, so we should work together. 

Thirdly, what should SAGE be doing? 
Again, I think we’re on track for the most 
part, although with a long way to go. 
Looking back at our purposes, it seems to 
me that the to do list should include: 
education, certification, expanding 
beyond the UNIX box, speaking for the 
community (which includes involvement 
in the standards process, representing 
sysadmins to the vendor community, and 
working with sysadmin management), 
and expanding the technical advance¬ 
ments in our field. 

Our educational needs include work in 
the “formal” and “informal” areas (see 
my December, 1997, ;login: article) and- 
developing a continuing education plan 
both within and outside of the certifica¬ 
tion arena. We need to expand downward 
into high schools, as well as to people 
who are thrust into parts of our job from 
other (often nontechnical) backgrounds. 

We are doing better at becoming less 


UNIX-focused, but we need to ensure we 
don’t move from “one OS” to “two OSs” 
and instead generalize to “any OS” - 
applying rules of scale. We have been 
talking recently in the executive commit¬ 
tee meetings about closer ties with ven¬ 
dors, but haven’t yet worked out any 
plans. This is something for progress 
during the next couple of years. 


Our current standards involvement is 
pretty minimal: we’ve asked Nicholas 
Stoughton, the USENIX Standards 
Liaison, to add our interests to his reper¬ 
toire. He’s done that, but we need to fol¬ 
low through with some work on our part 
now. 


Other than the booklets on job descrip¬ 
tions and security for managers, we’ve 
not done much for our employers/man¬ 
agers yet, and need to improve our own 
lot by improving theirs. 

Finally, there is another difficult item on 
the to do list: technical research and 
development. SAGE has a history, 
through the USENIX Association and 
general conferences, of creating new tools 
or methods and reporting on them to the 
community at large. As we’ve become 
more separate from our USENIX devel¬ 
oper community and more sysadmin ori¬ 
ented, we have been losing sight of that 
function. Our time is so limited by the 
pressures of our jobs we have that we’re 
often lost in the trees and can’t see the 
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forest. We wait for someone else to do the 
development, or worse, wait for vendors 
to decide what we need, without even 
giving them a hint. We need, as an orga¬ 
nization, to find a way to sponsor new 
development work specifically for sysad¬ 
mins, and get it going. 

The final question is “How do we get 
there?'' It takes a lot of work, most of 
which must of necessity be by volunteers. 
Given the difficulties sysadmins have 
finding time to volunteer, careful coordi¬ 
nation of the volunteer time we come up 
with is important. We need to get out 
there and beat the bushes for new mem¬ 
bers, ties with vendors, paper writers for 
conferences, tool writers, article writers 
for dogitVy mentors, teachers, etc. We need 
people to help organize conferences, to 
help staff the SAGE booth at conferences, 
to respond with opinions when someone 
“flies” an idea. We need help in expand¬ 
ing the SAGE model to ensure that it 
properly covers N+1 operating systems. 
How we get there is through organization 
and coordination. It is our biggest and 
most important task ahead. 

Tm a sysadmin. We are trained by our 
daily work life to dive in and “do” on our 
own, often without regard to the possibil¬ 
ities for teamwork. One of the hardest 
things IVe had to do is to keep my mouth 
shut on the SAGE-AU board once I left 
that presidency, and allow the new office¬ 
holders to run things however they saw 
fit. Allowing others to have the freedom 
to do things their own way is hard, but is 
the key to delegation. This task is the one 
to which the next Executive Committee 
must first lend itself. Not only do we 
need the volunteers, but we need the abil¬ 
ity to manage and coordinate the work 
done. 

Elections for the Executive Committee 
are coming up. I can t overemphasize the 
importance of returning your ballot. We 
have around 4,000 members. Most cur¬ 
rent members of the committee received 
between 300 and 400 votes each, and you 
get one vote per position. That means 
that 10% of the membership elected us. 
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Our surveys received about the same per¬ 
centage of response. WeVe driven SAGE 
forward on the basis of our personal 
agendas and comments we received from 
a small number of you, I hope in the 
direction most of you wanted us to go. 


( SAGE Certification: Q&A ) 



Editor's Note: LISA will have a ''Great 
Debate" about SAGE's certification effort. 

I have asked Barb to supply some informa¬ 
tion and will follow up with an interview 
with her next month. RK 

Q. What are the benefits of certification? 

A. Certification has long been used in 
other fields and is fast becoming typical 
in the computing field. Certification 
provides: 

■ an objective means to evaluate 
prospective employees, 

■ a means for system administrators to 
evaluate their own skills, and 

■ a basis for educational curricula. 

Q. How is certification different from 
education? 

A. The goal of education is to impart 
skills and/or knowledge. The goal of cer¬ 
tification is to evaluate whether one has 
successfully attained such skills and/or 
knowledge. The two go hand-in-hand. 

Commercial educational programs typi¬ 
cally do not include any rigorous testing. 
If you paid for and attend a class, you 
“passed.” Certification is the missing eval¬ 
uation component. 


Formal higher education involves evalua¬ 
tions for pass or fail. However, it tends to 
be more broad and much less specialized 
than is required to satisfy quickly iiuctu- 
ating industry demands. 

Q. Why is SAGE developing a certifica¬ 
tion program? 

A. SAGE in the US and SAGE-AU are the 
only organized associations of system 
administrators. The best and most effec¬ 
tive certifications programs are those 
specified by the people who practice in 
that field. 

That is not sufficient motivation alone. 
The industry demand for system admin¬ 
istrators has been growing for many 
years. The supply of qualified system 
administrators has not kept pace. This is 
in part evidenced by the growing number 
of commercial system administration cer¬ 
tification programs. Certification is one 
way to mitigate this demand. 

Certification is one way SAGE is support¬ 
ing newcomers to system administration. 
Other projects include: 

■ fostering interest in computing starting 
in high school, 

■ supporting education through higher 
education, conferences, and 
publications, 

■ providing assistance to local groups, 
and 

■ developing a mentoring program. 

Q. What are the goals of the SAGE certi¬ 
fication effort? 

A. The field of system administration, 
while being only a small part of the com¬ 
puting field, is quite diverse. For this rea¬ 
son, SAGE certification will initially focus 
on “core competency.” As the program 
matures, certification may be extended to 
cover classifications or specializations, 
e.g., webmaster, postmaster, different 
operating systems, etc. 

In defining and implementing a certifica¬ 
tion program, SAGE has two fundamen¬ 
tal principles which it will uphold: 
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■ the evaluations must be of merit: use¬ 
ful and meaningful to the participant 
and the community, and 

■ cost must not be a barrier to participa¬ 
tion, i.e. purchase of books or courses 
will not be required. 

Q. Who is involved in the certification 
development process? 

A. The primary vehicle for the SAGE cer¬ 
tification project is the Certification 
Subcommittee. 

The subcommittee will make appropriate 
use of professional certification consul¬ 
tants. Just as system administrators are 
experts in their field, there are experts in 
the field of developing certification pro¬ 
grams and methods of evaluation. 

In addition, an Advisory Council has 
been established. The role of the Advisory 
Council is to provide a sounding board 
and feedback to the project. 

Q. What is the time frame? 

A. The three major phases to establish 
this certification program are: 

1. Definition (skill requirements and 
program logistics) 

2. Implementation 

3. Production 

The schedule calls for the definition 
phase to be completed by mid-1999 and 
the implementation phase to be complet¬ 
ed by early 2000. 

Q. Who will benefit from certification? 

A. There are two intended beneficiaries 
of a SAGE certification program: 

1. Budding system administrators who 
are interested in improving or defining 
their skills and/or having objective 
recognition of them. 

2. Hiring managers of system administra¬ 
tors who might benefit from an exter¬ 
nal objective evaluation of applicant 
skills. 

This potential certification program is 
not intended to license practicing experi¬ 


enced system administrators. 

Q. Why should 1 become certified? 

A. When (if) the SAGE certification pro¬ 
gram is implemented, there are several 
reasons to become certified. 

1. The certification program may be used 
as an educational goal. There are 
already several educational organiza¬ 
tions interested in providing educa¬ 
tional programs that impart the skills 
necessary to pass SAGE certification 
tests. Whether or not you actually take 
the tests, you may want to use educa¬ 
tional courses and tools geared toward 
SAGE certification. 

2. Certification, like any goal such as a 
college degree, provides an achieve¬ 
ment to strive for. Since SAGE certifi¬ 
cation would be a single source evalua¬ 
tion, it would provide an objective 
assessment of your skills. 

3. Also like other tangible goals, certifica¬ 
tion provides a recognizable result. Part 
of any certification program is recogni¬ 
tion. Those who become certified may 
do so in order to gain the recognition 
promoted by the program. This recog¬ 
nition could result in increased job 
opportunities and/or better tangible 
job credibility such as salary. 

Q. How may complex skills be tested? 

A. This question will be answered during 
the development of the program. 
Whatever testing methodologies are used, 
they have to meet the program goals. 
Recall those goals require that the testing 
be “of merit.” Therefore, any testing 
method which allows for rote memoriza¬ 
tion is not acceptable. There are profes¬ 
sionals who specialize in the development 
of testing methodologies. Such profes¬ 
sionals will be consulted to ensure an 
effective result. For example, testing for 
nursing or police work involves compo¬ 
nents that evaluate actual skills rather 
than “book knowledge.” 


Are You Preparing for 
the New Millennium? 

___ J 


by Tim Gassaway 

Tim is a member of the SAGE Executive Committee. 
<gassaway@usenix.org> 


The end of the year is upon us already 
and ifs time to start thinking about 1999. 
That’s right - we are only about 365 days 
from the new millennium. With all the 
rage over Y2K issues, system administra¬ 
tors around the globe will be challenged 
more than ever to be the ultimate prob¬ 
lem solvers. Therefore, it’s vital that you 
have an organization like SAGE around 
to support you at this critical time. 


SAGE members can support one another 
by participating in a moderated exchange 
of information on current and future 
issues that are important to system 
administrators. If you’re not already sub¬ 
scribed to <sage-members@usenix.org>, now 
is the time. 


Keeping that in mind, I would like to dub 
the year 1999 as the year of the volunteer. 
Remember the famous quote from JFK, 
“Ask not what your country can do for 
you - ask what can you do for your 
country.” Well just substitute “SAGE” for 
“country” and I think you’ll get the mes¬ 
sage. I would like to challenge each mem¬ 
ber of SAGE to volunteer just a small 
fraction of time to assist with a SAGE ini¬ 
tiative or event. 


Wliat initiative or event? Well, 1 have list¬ 
ed a few below and invite you to visit the 
<http:www.usenix.org/sage> for additional 
initiatives and events. 

The 1st Conference on Network 
Administration, scheduled for April 7-9, 
1999 '<http:www.usenix.org/events/neta99> will 
provide a wealth of information perti¬ 
nent to network and system administra¬ 
tors. The 2nd Large Installation System 
Administration of Windows NT 
Conference is scheduled for July 14-16, 


December 1998 ;login: 


37 


SAGE NEWS & FEATURES 









1999, in Seattle, Washington. There is still 
time to submit proposals before the 
deadline on February 23, 1999. The 13th 
Systems Administration Conference 
(LISA ‘99) is the last one before the year 

2000. This conference is scheduled for 
November 7-12,1999, in Seattle. We are 
going to have a great time finding out 
about all those last minute Y2K issues. 
Now is the time to start planning to par¬ 
ticipate in the conference by submitting a 
proposal. 

In addition, the SAGE series editor has 
issued a request for proposals for the 
Short Topics in System Administration 
series. The topics are: 

■ Effective Customer Support 

■ Monitoring Techniques and Practices 

■ The Role of Postmaster 

■ The Role of Webmaster 

The list of opportunities is endless. So 
here’s the deal: send me an email <Subject: 
SAGE Volunteer> listing what your interests, 
skills, and availability are, and we will put 
you to work. I’ll be expecting a full mail¬ 
box soon. 


( Making Users Happy~) 


By Sean Kamath 




Sean Kamath is the manager of the CPID Engineering 
System Administration (CESA) Team. CPID is the Color 
Printing and Imaging Division of Tektronix. 


<kamath@pogo.WV.TEK.COM> 



''If users are made to understand that the 
system administrator's job is to make com¬ 
puters run, and not to make them happy, 
they can, in fact, be made happy most of 
the time. If users are allowed to believe that 
the system administrators job is to make 
them happy, they can, in fact, never be 
made happy. Furthermore, in their quest 
for happiness, they will cause enough 
resources to be diverted to trying to make 
them happy that the computers will no 
longer run!' 


- Paul Evans (as quoted by Barb Dijker in 
“Managing Support Staff,” LISA ‘97) 


A couple of days ago I started a mini 
email flame-fest on the SAGE mailing 
list. I responded to a comment about 
making users “happy.” My response was, 
basically, “Who cares if the users are 
happy, what matters is making them pro¬ 
ductive.” (Of course, I really do care, but I 
was cranky that day.) Needless to say, 
there were a number of responses about 
how keeping the users happy was the 
most important thing they do, particular¬ 
ly from the ISP community. I’ve been 
spending a couple of days thinking about 
this, and I still don’t agree. The focus of 
system administration is Productivity, 
not Happiness. 


Throughout this article. I’m going to use 
the word “productive” a lot, but keep in 
mind I really mean “able to get some¬ 
thing done in an acceptable time-frame 
with acceptable costs.” “Productive” is just 
shorter. 


I understand that there are significant 
differences among corporate, ISP, govern¬ 
ment, educational, and other types of 
system administration. However, the title 


“system administrator” has an implica¬ 
tion that transcends these differences. We 
“administer systems,” not “make people 
happy” or “entertain people” (at least, 
generally, not intentionally). The word 
“system” in this case really means more 
than just the hardware and software on 
the machines we run; it includes net¬ 
works and people. Our goal, first and 
foremost, is to make sure that the systems 
we administer are useful and productive. 
Otherwise, why have the system to begin 
with? Having machines sitting around in 
dark rooms with no one using them (or 
their output) is not very productive for 
anyone. 

This raises the question “Who should be 
responsible for determining if the users 
are productive?” Depending on functions 
and/or organizations, different people or 
groups of people have this responsibility. 
In corporate shops, it is usually the man¬ 
ager of the end user who determines pro¬ 
ductivity. In educational areas, it might 
be the professors. For ISPs, clearly it’s the 
end user. I’m not sure who it is in gov¬ 
ernment, probably appropriations com¬ 
mittees. 

What it boils down to is that our job is to 
help people get things done. The end 
result is usually a satisfied customer, one 
way or the other. The important differ¬ 
ence between targeting end-user produc¬ 
tivity instead of happiness is that the for¬ 
mer is measurable (albeit often not by the 
sysadmin directly), objective, and visible 
to others in a nonemotional way. You also 
have a better chance of justifying deci¬ 
sions on the basis of increasing produc¬ 
tivity, rather than making users happy. 

Often the end users are not fully able to 
determine what will make them happy - 
or even productive - especially in the 
long term. For example, the end user 
might demand that you stripe a set of 
disks. But they might have been happier 
to have a RAIDS or RAID O+I array after 
the disk died and had to suffer a 24-hour 
restore, assuming there was enough disk 
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space. The balance here is to meet their 
needs, both short- and long-term, in 
terms of productivity. 

By the way, I’m not advocating the tradi¬ 
tional RTFM, since in many cases one 
cannot expect an end user to read docu¬ 
mentation and get out of it what a sysad¬ 
min can. Yes, we would all like people to 
help themselves first, before coming to us 
for further assistance, but the fact is 
that’s not how things work. How would 
you feel if your doctor said, “Read the 
manual” every time you went for an 
office visit? Doctors are paid for their 
experience and knowledge, just as we are 
paid for ours. It’s possible that end users 
can figure out stuff on their own from 
documentation, but it’s more productive 
(for them) to get a quick answer from 
someone who already knows. 

There is also a tremendous sense of what 
I call perceived productivity: since an end 
user has all the equipment he or she 
needs, that user will automatically be 
productive. But if you put the world’s 
fastest UNIX box on a Windows-only 
user’s desk, it doesn’t matter how fast the 
UNIX box is; they won’t know how to 
use it. Don’t fall into the trap of believing 
that if we give an end user everything we 
would need to get the job done quickly, 
that the user has everything he or she 
needs to get the job done quickly. 

A co-worker I was talking to about this 
topic said that making users happy 
sometimes is more important than pro¬ 
ductivity. He cited a major Internet 
provider that has a lot of GUI-based 
stuff, but not a lot of substance behind it, 
implying that its focus is happy users 
instead of productive ones. My response 
was that their goal was to get as many 
people productive (i.e., getting some¬ 
thing out of the service) as they could, 
and that his perception of what would 
make the users productive didn’t matter. 
It’s the users of the ISP that decide if 
they are getting their Web pages and 
other services for which they are paying. 


By facilitating a user’s productivity, you 
tend to make that user “happy.” 
Therefore, you should focus on produc¬ 
tivity as the goal. Regardless of how you 
choose to view end users (customers, 
pests with requests or losers, team mem¬ 
bers, or coworkers) the point is that we 
were hired (by someone) to help them 
get something done. Tom Limoncelli’s 
excellent paper at LISA ‘97 (“Turning the 
Corner: Upgrading Yourself from ‘System 
Clerk’ to ‘System Advocate’”) has an 
excellent section on your attitude as a 
system administrator. And remember: In 
one way or another, we’re all end users, 
and we all have something we want to 
get done. Making users productive - not 
making them happy - should be your 
primary focus. 

Making your spouse happy, now that’s 
another story. 



By Pat Wilson, Amy Kreiling, and 
Greg Rose 



The Nominating Committee is pleased to 
present a strong slate of nominees for 
upcoming SAGE election. Each of the 
following candidates has indicated 
her/his willingness to serve on the SAGE 
Executive Committee for the 1999-2000 
term. 

The Committee nominates the following 
individuals: 

■ Barb Dijker, Labyrinth Computer 
Services 

■ Tim Gassaway, Auspex 

■ Xev Gittler, Goldman, Sachs & Co. 

■ Geoff Halprin, The SysAdmin Group 

■ Jim Hickstein, consultant 


Report of the 
Nominating Committee 

V _ J 


■ Bryan McDonald, Global Networking 
and Computing, Inc 

■ Hal Miller, University of Washington 

■ David Parter, University of Wisconsin 


■ Peg Schafer, Harvard University 

■ Bruce Wynn, Collective Technologies 

The election for the SAGE Executive 
Committee will be held in December, 
1998, with the newly elected committee 
members taking office no later than 
February 1,1999. 


SAGE members will have an opportunity 
to meet the candidates at the upcoming 
LISA ’98 conference in Boston; there’s 
a Candidates’s Forum scheduled at the 
conference on Thursday, December 10, 
from 5:30-6:30pm. Please come, then 
vote responsibly. 
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Enough SNMP to Be Dangerous 
Parti 

V_—_^_ J 

This is the first of a series of articles dedicated to teaching typical UNIX system 

administrator types - people who can compile public domain software and have 
some idea about TCP/IP - how to do UNIX-style hackery with SNMP. It is not an 
elegant and systematic approach to SNMP, but it should give you enough back¬ 
ground to be dangerous. 

SNMP, the simple network management protocol, is one of those simple but powerful 
(and therefore brain-bendingly complicated) concepts. The simple part of SNMP is that 
it basically supports only two commands and a few variations on them. The commands 
are get, to get the value of a variable, and set, to set the value of a variable. The hard 
part is figuring out (1) what variable you want and (2) what the value means. 

Because it doesn’t require vast intelligence to speak SNMP, all sorts of things speak it. 
Among the devices with SNMP running on my local-area network, where we weren’t 
using SNMP and therefore hadn’t done anything special to turn it on, are almost every 
UNIX box, every router or switch with an IP address, every printer with an IP address, 
every NT machine or NT-variant machine, a significant number of machines running 
Windows 95, and the voicemail system. 

This means that a person armed with some freely available tools, some basic SNMP 
knowledge, and some interest in poking at network devices with blunt sticks, can come 
up with all sorts of interesting and occasionally even useful information. 


Freely Available Tools 

The first thing you need, of course, is the tools. The pre-eminent tool suite for SNMP is 
from the University of California at Davis, and is available from 
<httpy/vvvvw.ece.ucdavis.edu/ucd-snmp>. On top of that, you will probably want a Perl library; I 
use G. S. Marzot’s. (I have to admit, I didn’t do a comprehensive survey, 1 just picked the 
first one I ran across that worked): <ftp://ftp.wellfleet.com/netman/snmp/perl5/SNMP.tar.gz>. 


Basic SNMP Knowledge 

One of the not-so-simple things about SNMP is that it has its own terminology. This is 
not entirely unreasonable as a way of keeping you from making assumptions, but it can 
be daunting. At base, SNMP has two parts. One of them is a server that sits on the 
device; this is usually called an “agent.” The other one is a client that asks questions; this 
is usually called a “manager.” 

The main reason these things are not just called clients and servers is that the server half 
may be capable of initiating messages itself (called “traps”), in which case something 
that’s normally a client needs to be sitting around listening for them. In this situation, 
the client-server paradigm is bent rather badly. 

The objects that the agent and the manager exchange are defined by something called a 
MIB (Management Information Base). A MIB specifies a mapping between long dotted 
numbers, human readable names, and pieces of information. For instance, 

.1.3.6.1.2.1.1.1.0 is more familiarly known as system. sysDescr.O, and it contains a 
description of the system. This is what the MIB that says this looks like: 
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RFC1213-MIB DEFINITIONS : := BEGIN 

IMPORTS 

mgmt, NetworkAddress, IpAddress, Counter, Gauge, TimeTicks 
FROM RFC1155-SMI 
OBJECT-TYPE 
FROM RFC-1212 

mib-2 OBJECT IDENTIFIER : : = { mgmt 1 } 

system OBJECT IDENTIFIER : : = { mib-2 1 } 

sysDescr OBJECT-TYPE 

SYNTAX Displaystring (SIZE (0..255)) 

ACCESS read-only 
STATUS mandatory 
DESCRIPTION 

"A textual description of the entity. This value should 
include the full name and version identification of the sys¬ 
tem's hardware type, software operating-system, and networking 
software. It is mandatory that this only contain printable 
ASCII characters.” 

::= { system 1 } 

Most agents implement at least two MIBs, a standard base MIB and one specific to the 
device. Many of them implement more than that. A manager that talks to many differ¬ 
ent agents will quickly end up using dozens of different MIBs. That’s okay, because the 
manager software we’re using is easygoing in several ways. First, it doesn’t really care if 
it has a MIB or not; if you’re willing to use numbers or “get next” to get unparsed infor¬ 
mation, the software will gladly forgo the work of translating things into names. 

Second, it will read text form MIBs. Fancier management software generally wants to 
compile MIBs into more efficient forms; with the UCD package, you can just FTP over 
text files and shove them into its directory. I’ll talk about how to find MIBs later; UCD 
provides the most basic MIBs along with the software. 

The final term you need to understand is “community string.” The community string is 
a token passed from the manager to the agent; you might want to think of it as a 
remarkably weak password (it is passed around in cleartext). The device you’re talking 
to will use the community name you give it to decide what data you should have access 
to. The default community is “public,” which should theoretically give access only to 
“safe” information. In practice, vendors have an unfortunate tendency to allow all 
SNMP to the community “public”; this may include the ability to get information you 
might not want given out to anybody in the universe, like the names of all the accounts 
on your machine, or worse yet it may include the ability to do sets on arbitrary vari¬ 
ables. Since SNMP is used for device management, and it has only two commands, set 
does a number of things that you might not expect; if you’re thinking “What harm can 
setting a variable do?” consider the possibility that it’s the “Reboot now” variable, and 
has just been set to “true.” Obviously, this sort of approach provides the ability to do all 
sorts of truly moronic SNMP tricks, most of which will not be discussed here. 

Poking at Network Devices with Blunt Sticks 

Once you have installed the UCD tools, pick a host that you’re reasonably certain is 
running SNMP, and try this: 

snmpget hostname public system.sysDescr.0 
which will return something like 

system.sysDescr.0 = Silicon Graphics Challenge/1 running IRIX 6.3 
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In practice, vendors have 
an unfortunate tendency to 
allow all SNMP to the 
community “public"; this 
may include the ability to 
get information you might 
not want given out to any¬ 
body in the universe, like 
the names of all the 
accounts on your machine, 
or worse yet it may include 
the ability to do sets on 
arbitrary variables. 








For a stupid SNMP trick, 
try asking all your 
local systems for 

system.sysDescr.0 and 

see how many of them 
return something that 
complies to the RFC 
definition. 


if it works, and something like 
No Response from hostname 
if it doesn’t. 

Obviously, the first parameter to snrrpget is the name of the host you want to talk to. 
The second is the community string. If you, or your network managers, already know 
about SNMP, “public” may not be an appropriate community string, or may give you 
only tame information suitable for the sort of tricks I intend to talk about. If you get 
“No Response” from a device that you are sure should be speaking SNMP, try asking 
somebody if you need to use another community string. 

The second parameter, system. sysDescr. 0, is the variable name that you want the 
value of. system.sysDescr. 0 happens to be the first value defined by the absolutely 
most common MIB for SNMP devices to implement, which is usually called MIB-II, is 
defined in RFC1213, and is provided with the UCD SNMP libraries. sysDescr also 
happens to be both human-comprehensible and relatively amusing. 

For a first stupid SNMP trick, try asking all your local systems for system.sysDescr. 0 
and see how many of them return something that complies to the RFC definition 
above. 

Here’s a sample of my results (nonprintable characters have been converted to ASCII 
equivalents). 

Fails the mandatory requirement to be printable: 

NX-500 ,2.0.6E'"@ 

CyberSWITCH-100 (ISDN v5.2) v2.0^M 
Copyright (c) 1996 Cabletron Systems, Inc.'^M 
Copyright (c) 1995-1996 FlowPoint Corp.'^M 
Copyright (c) 1985-1996 MPX Data Systems, Inc.^M 
All Rights Reserved 

(What are they copyrighting here? Is it legal for me to publish this?) 

Entirely printable, but missing either hardware or software. Note that Cisco manages to 
list software only on one machine, and hardware only on another. 

Linux version 2.0.32 (root@linux95.corp.sgi.com) (gcc version 
2.7.2.1) #1 Tue Dec 16 21:34:57 PST 1997 

Microsoft Corp. Chicago Beta 
Cisco Systems Catalyst 1900 

Cisco Internetwork Operating System Software 

lOS (tm) 4500 Software (C4500-J-M), Version 11.1(7), 

RELEASE SOFTOARE (fc2) 

Copyright (c) 1986-1996 by cisco Systems, Inc. 

Compiled Wed 23-Oct-96 21:16 by tej 

Not interpretable by nonexperts: 

X8523L-3.4.7 
ES/1 ATX 

ATX Release 3.1.11 24-Jul-96 

PPE 512-0078-003 B 0002E400E2C5 

IF512-0054-003 X10002E400AE76 

QE512-0069-00B0002E4005FBC 

QE512-0069-00B0002E400C284 
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And just to prove that it can be done, a variety of vendors with their own eccentric for¬ 
matting, but the right information (note that Tm willing to live without the network 
version, which only some of them include - a more draconian reading of the spec 
would pass only the last three). 


Hardware: x86 Family 6 Model 1 Stepping 9 AT/AT COMPATIBLE 
Software: Windows NT Version 3.51 (Build Number: 179 
Multiprocessor Free ) 

SGICOR - OCTEL OVERTURE 300 Voice Mail System, Id: 302164 Rev 2.0.1 


Silicon Graphics Challenge/4 running IRIX64 6.2 
SunOS cambio 5.5.1 Generic sun4m 

Tektronix, Inc., Phaser 360, PhaserShare Series B Network Interface, 
(5.44/1.62/9.16) 


Model; LANplex 2500, h/w rev; 06-0D, s/w rev; 04-03-00-07 

80486 DOS 6.20 

Windows 3.10 Enhanced Mode 

NetManage SNMP 4.50 

IBM RISC System/6000 

Machine Type: 0x0030 Processor id: 000019913000 

The Base Operating System AIX version: 03.02.0000.0000 

TCPIP Applications version: 03.02.0000.0000 

HP3000 SERIES 948, MPE XL version B.40.00 NS Transport version 
B.05.00 

I also ran into one machine that was running SNMP but did not have 
system. sysDescr; this is probably a symptom of gross misconfiguration. 

Finally, here’s the world’s stupidest Web-based SNMP tool. It consists of a Web page 
with a form: 


<!DOCTYPE HTML PUBLIC ”-//IETF//DTD HTML//EN"> 

<HTML VERSION=”2.0"> 

<HEAD> 

<TITLE>Web Front End for SNMP Queries</TITLE> 

</HEAD> 

<BODY> 

<H1> Web Front End for SNMP Queries</Hl> 

<FORM METHOD="GET" ACTION="snmpquery”> 

<P> What host? 

<INPUT TYPE="TEXT'' NAME="hostname" SIZE=20> 

</P> 

<P> What variable? 

<INPUT TYPE="TEXT" NAME= "variable" SIZE=40> 

</P> 

<P> What instance? 

<INPUT TYPE="TEXT" NAME="instance" SIZE=4 VALUE="0"> 
</P> 

<P> 

<INPUT TYPE="SUBMIT" VALUE="Run Query"> 

</P> 

</FORM> 

</BODY> 

</HTML> 
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And its accompanying processor: 

#! /usr/bin/perl 5 

use SNMP; 

use CGI qw(:all); 

print header; 

print start_htinl(-title=>"Results of SNMP query"); 

print hi ("Results of SNMP query”); 

$hostnaine = param('hostname') ; 

$variable = param('veiriable') ; 

$ instance = param (' instance') ; 

if ($sess = new SNMP::Session(DestHost=>$hostname)) { 

$value = $sess->get {[$variable, $instance]); 

$error = $sess->{ErrorStr}; 
if ($error){ 

print p(b("Error: $error\n")); 

} 

print p( "Value of $variable. $instance for $hostname is $value\n"); 

} 

else { 

print p("Error: could not bind $hostname\n"); 

} 

print end_html; 

No points will be awarded for finding any of the obvious shortcomings of this little sys¬ 
tem - except the sudden appearance of something called an “instance ” At this point, 
we’re still dealing with things that are one to a device; each device has exacdy one sys¬ 
tem description, for example. That means that so far IVe been able to get away with 
throwing around system. sysDescr and system. sysDescr . 0 without ever quite men¬ 
tioning where the trailing .0 comes fi:om. However, SNMP also deals with things 
that come in multiples. For example, later on we’ll probably be interested in 
interfaces. if Table. i f Entry • ifDescr, which describes a network interface. Most 
network devices of interest have multiple network interfaces, and so there are multiple 
instances of interfaces. ifTable. if Entry. ifDescr, one for each interfiice. I could 
have just left this hard-coded at 0 for now, but then I would have had to reprint a slight¬ 
ly modified program when we got to multiple-instance variables, and that would be 
annoying. 

Next time: We move on to more interesting parts of MIB II, and branch out into more 
interesting programming. 
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[nT Accounts: A Starting Point 

I have often been asked about the different types of accounts in Windows NT. 
This time I’ll talk a little bit about each of them, how they differ, and what they 
can be used for. 

NT and UNIX Parallels 

I find ifs simplest to describe Windows NT accounts to experienced UNIX users by 
using NIS as a reference. To begin, think of the NT domain as an NIS domain (and for 
those of you who care, NTS domains are similar to NIS+ domains). Similarly, the NT 
Security Accounts Manager Database (SAM) is roughly equivalent to the UNIX passwd 
file. An NT Member server is roughly equivalent to a UNIX server which is NOT an 
NIS master or slave (but is part of the NIS domain). A Windows NT Primary Domain 
Controller (PDC) is roughly equivalent to a UNIX NIS master, and a Windows NT 
Backup Domain Controller (BDC) to a UNIX NIS slave server (NOTE: Unlike UNIX 
slave serves, the BDC does not have ifs own separate SAM; it uses the Domain SAM 
exclusively). Whew! That’s a lot of relationships! See the table on the right for reference. 

Trust 

Before we go any further, we have to talk about “trust” and how it is used in Windows 
NT Domain structures. When one NT domain “trusts” another, then the accounts and 
groups defined in the “trusted” domain can be used for authentication and authoriza¬ 
tion in the “trusting” domain. For example, let’s say the account “pcc” is a member of 
the Windows NT domain “NTS” (noted by the syntax “NTS\pcc”). Further, let the 
Windows NT domain “IWI” trust “NTS” (so that NTS is trusted, and IWI is trusting). 
Then I can log on to a machine that is part of the IWI domain with the account 
“NTS\pcc”. The IWI domain would know to contact the trusted domain and validate 
my logon credentials. For the sake of this article, it is important just to understand that 
Windows NT domain accounts can be used in other domains, if a trust relationship has 
been established. 



<pcc@ntsinc.com> 
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Windows NT UNIX Equivalent 


NT Domain 
SAM 
PDC 
BDC 

Member Server 


NIS Domain 
password file 
NIS Master 
NIS Slave 

Server that uses the 
NIS domain 


Account Types 

With these analogies, let’s look at the three types of Windows NT accounts and their 
usage. 

The first type of account is the Local account. It is like a user account in the 
/etc/passwd file on the UNIX workstation. Although the machine is part of an NIS 
domain, the accounts in the local /etc/passwd file are valid for that machine alone. 
This is true for NT as well. Any account defined in the SAM of the individual worksta¬ 
tion or member server is for that host alone. Local accounts are only valid when used on 
the machine for which they were created. There is also a special class of local accounts 
that are called “built-in.” These accounts are used mosdy for system purposes and are 
not usually modified. Some of the built-in, or special accounts, are: Creator/Owner, 
System, and others. These accounts are seen when setting access control entries, but are 
not seen when managing regular local user accounts. 

The second type of account is the Domain account. These accounts are defined in the 
SAM on the PDC, much as NIS accounts are defined in the /etc/passwd file on the 
NIS master server. These accounts, like NIS accounts, are valid for any/all machines that 
participate in the domain, and any domain for which this domain is trusted. 
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There are three type of 
Windows NT accounts: 

m Local (in SAM on indi¬ 
vidual Workstation or ' 
Member server) 

m Domain (in SAM on PDC 
and replicated to the 
BDCs) 

m Domain Local (in SAM 
on PDC, but are restrict¬ 
ed to the PDC and 
BDCs). 

Just like in UNIX, they 
differ in their scope and in 
their administration. 


The third type of account is the Domain Local account. It is actually a Local account on 
the PDC as defined above. Since the machine is the PDC, and the PDC’s SAM is the 
SAM for the BDCs as well, this account becomes “local” to the PDC and all BDCs in the 
domain. Normally, a user defined in the SAM on the PDC would become a “Domain 
User” and would have the characteristics (described in the paragraph above) of such an 
account. A Domain Local account, however, is specially marked and is not seen in the 
regular list of “Domain Users.” 

Which Account To Use 

You might wonder, “When might I choose one account type over another?” Local 
accounts are typically used when you desire to restrict access to an individual machine. 
Domain accounts (by far the most common) are applicable when you want to allow 
access to a wide range of resources. Finally, use Domain Local accounts when you 
require an account that will have access to resources on Domain Controllers but isn’t 
trusted outside of the Domain itself. 

All NT accounts are administered through a “User Manager,” but, depending on the 
account, you’ll need the right manager! All local accounts are administered through the 
“User Manager” (musrmgr.exe) directly on the host itself. All domain-related accounts 
are administered with the “User Manager for Domains” (usrrogr .exe) from any host 
that has the program and has permission to connect to the domain. 

While the naming convention may be new, many of the same concepts that apply to 
accounts in UNIX also apply to NT. If you’ve mastered the fundamentals of UNIX 
logins and NIS domains and servers, you’re well on your way to understanding NT 
accounts and domains controllers. 
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Knit One, Perl 5.005 

There’s a New Perl on the Block 

The latest “major” revision of Perl, version 5.005, is now available. I'll discuss 
some of its new features, and some of the less stable experimental additions to 
the language. 

Keep Your Feet Dry 

Although the release of a major revision is exciting, you shouldn’t immediately down¬ 
load Perl 5.005 and install it on your system. In a production environment where users 
depend on the reliable operation of a large set of Perl modules and programs, this 
would be a disaster. For one thing, Perl 5.005 is binary incompatible with previous ver¬ 
sions of Perl. This means that any C- or C++-based modules that are installed in your 
Perl tree must be rebuilt for Perl 5.005. Some of those modules may not even compile 
against Perl 5.005 because the Perl API has changed; therefore, you may have to wait for 
new 5.005-compatible versions of those modules to be released. Another issue is that 
while maintainers have generally taken great pains to ensure backward compatibility 
with existing Perl scripts, incompatibilities due to changes and/or bugs no doubt do 
exist. 

If you are running Perl on a machine on which you are the only user, or where it is 
not being used for critical applications, you can convert to Perl 5.005 by taking an 
inventory of what modules are installed on your system (perhaps with the help of 
perldoc perl local or the CPAN module’s autobundle command), building Perl 
5.005, then reinstalling all of the modules that you want to keep. 

On the other hand, in a production environment where a stable Perl is a critical part of 
daily operations, you will have to create an independent Perl 5.005 installation, reinstall 
the necessary modules there, then have your users test their applications against this 
separate installation. Applications that won’t run under 5.005 can be fixed, or if that 
isn’t practical, “hardwired” to use an earlier version of Perl kept around for backward 
compatibility. Only after everything is tested and stable - a process that might take 
weeks or months - should you make the newer version of Perl your new standard. 

It’s just a suggestion, but if I were contemplating moving a production environment to 
a newer version of Perl, I would wait a few months and hope for more maintenance 
releases of Perl 5.005 in the interim. 
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This column refers to the most recent ver¬ 
sion available as of this writing, Perl 
5.005_02. There may have been 
additional releases by the time you read 
this article, but you shouldn't expect any 
radical advances or changes in the 
Immediate future. 


What about Threads? 

Perl 5.005 was originally supposed to include threads support. To a certain extent, it 
does, but as of 5.005_02, threads are still classified as an experimental feature. I’d like to 
discuss threads programming in Perl, but the time is not yet right. 

Okay, What about the Compiler? 

Development on the Perl compiler (also known as b) continues. While the compiler 
itself is still considered an experimental feature, there are a number of compiler-related 
modules that are already useful to developers. It’s also instructive to get a quick 
overview of the compiler. 

The Perl compiler works by parsing Perl source code into an intermediate representa¬ 
tion. Then, with a suitable “backend,” it transforms the intermediate representation into 
something else. The CC backend, for example, creates optimized C code. The resulting C 
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There have been quite a 
few internal changes to 
Perl regular expressions in 
Perl 5.005. Regular 
expressions are now more 
efficient, a number of bugs 
have been fixed, and the 
regular expression code 
in Perl itself has been 
somewhat cleaned up. 


code must then be compiled with a C compiler to produce an executable program. For 
example, here’s a short program, which we’ll call cc-test .pi: 

print "Welcome to compiled Perl!\n"; 
for $i (1..10) { 

print "$i times $i is ", $i * $i, "\n"; 

} 

You can produce a corresponding C program, cc-test.c, with the somewhat unintu¬ 
itive command: 

% perl -MO=CC,-occ-test.c cc-test.pl 

From there, you need to compile and link this C program. You can do it directly using 
the cc_hamess program, but the process is simpler if you use another program called 
perlcc. perlcc takes care of the intervening steps automatically. For example: 

% perlcc cc-test.pl 

will first run the Perl compiler to produce C source code, then compile and link it into 
an executable called cc-test. When you run cc-test, it works just as if you were run¬ 
ning the original Perl source in cc-test.pl. 

This is nice as far as it works, but as the documentation states repeatedly, the Perl com¬ 
piler is buggy and still experimental. However, there are some compiler-related features 
that you may find interesting. For example, there is another backend called Xref that 
can be used to produce a (somewhat cryptic) cross-reference listing of some of the con¬ 
tents of the Perl source: 

% perl -MO=Xref cc-test.pl 
cc-test.pl syntax OK 
File cc-test.pl 

Subroutine (definitions) 

Package UNIVERSAL 
AVERSION sO 
&can sO 

ficisa sO 

Subroutine (main) 

Package main 
$i 5, 5, 5, 5 

★i 4 

You might also find the Lint and Deparse backends useful. For more information 
about the compiler, use the perldoc command to read the documentation for B, B: :CC, 
0, perlcc, and follow the references to other modules and programs as necessary. 

Not So Regular Expressions 

There have been quite a few internal changes to Perl regular expressions in Perl 5.005. 
Regular expressions are now more efficient, a number of bugs have been fixed, and the 
regular expression code in Perl itself has been somewhat cleaned up. There are a fair 
number of user-visible changes as well. First, there are some new regular expression 
atoms. For example, there are now atoms for pattern lookbehind: 

@foos = /\bfoo.*?\b/g; # find all words beginning with foo 

@nofoos = / (?<=\bfoo) . *?\b/g; # find all words beginning with 

# foo, but leave off the foo 

There are also atoms for “conditional” expressions, atoms that affect backtracking, and 
even atoms for executing arbitrary Perl code as a regular expression is matched. 

Another addition is the re pragma module, which controls various aspects of regular 
expression behavior. One use for re is debugging output: 
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% perl -Mre=debug -e V ' 

conpiling RE 
size 8 first at 1 
1: EXACT <">(3) 

3: MINMOD(4) 

4: STAR(6) 

5: ANY(O) 

6: EXACT <”>(8) 

8: END(O) 


The qr// (regular expression quoting) feature greatly simplifies the efficient use of reg¬ 
ular expressions that aren’t known until run time. The contents of qr// are a regular 
expression “string” (the same as in an ordinary match operator m//). The result of qr// 
is a scalar that can be used standalone like a match operator, or incorporated efficiently 
into other regular expressions: 


print "Field to match: 
chomp ($field = <>) ; 

$re = qr/$field/im¬ 
print "Type in a line: "; 

print <> /$re: (.*)/, "\n"; 


# For example, 'subject' 

# /i means ignore case 

# For example, 'Subject: some perl 

# stuff' 

# prints 'some perl stuff' 


The new features are documented in the perlre man page, the re module’s documen¬ 
tation, and the qr// entry in the perlop man page. 


Lots More New Stuff 

There are many more small changes and improvements in Perl 5.005. Here are some of 
the more stable (nonexperimental) ones. 

■ foreach (1.. 1000000) is now optimized so that it does not construct a temporary 
list one million elements long. 

■ You can now use foreach as a statement modifier. For example: 

print "The number is $_\n" foreach (1..10); # prints 10 numbers 

■ The fields and base pragmas allow you to add more compile-time semantics and 
checking to your Perl classes. 

■ Perl is more tolerant of carriage returns in source files. DOS-formatted (CR-LF) Perl 
source used to cause fatal errors; this is no longer the case. 

■ Tied arrays and handles are better supported. 

For More Information 

For more about what’s new in Perl 5.005, check the documentation. You can build Perl 
5.005 and read the perldelta man page, or you can inspect it online at any CPAN mir¬ 
ror site, for example, <http://www.perl.com/CPAN-local/doc/manual/html/pod/perldelta.html>. 
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" Toolman: Generating Web Pages with sh and ' 
^ make, Part 1 __^ 

Yeah, yeah, I've been hearing plenty lately about using Perl to generate Web 
pages. But I’ve been doing the same thing for a while now with the humble ol’ 
shell. Basically, I use the Bourne shell and its intrinsic string-based processing 
as a macro-processing language to generate HTML. Arguably, Perl or even m4 or 
various other scripting or macro languages [1] would be better suited for this 
purpose, but unless your Web pages are going to be fairly complex or extensive, 
good ol’ sh does quite a nice job, thank you. Throw in some appropriate script¬ 
ing and a makefile, and you can automate processing - and even generate 
various versions of the same pages, for example, for prototyping or for different 
network sites. 

Dubious as these claims may seem, the techniques Tm going to describe are really quite 
practical. What it gets down to, though, is that Tm just one of those incorrigible (and 
unrepentant) sh hackers at heart. So if you’ve got a hankering to do some shell and 
make programming to whip out consistent, easily maintained HTML code, please read 
on. And if you’re one who prefers an alternative scripting language, these concepts are 
likewise applicable. 

Due to space considerations, we’ll cover this material in two parts; fortunately the con¬ 
tent easily accomodates this. In this first installment, we’ll talk about the shell, and in 
the February issue of we’ll cover make. 

Tutorial Or Not Tutorial? 

This article will not be a tutorial on shell programming or on writing makefiles (or on 
writing Web pages, for that matter), but will demonstrate how these tools can be 
applied in the context of Web page generation. And by generation of Web pages and 
HTML, I mean the pregeneration of static Web pages only, not dynamic generation or 
CGI techniques. (The latter are within the realm of possibility, I just haven’t messed 
with it.) Please note that my use of these methods is a work in progress, so you will like¬ 
ly be able to improve upon what is presented here. 

Objectives: Consistency, Simplification, Automation, Mutability 

We want to satisfy several objectives with our choice of tools for Web page generation. 
One is to provide consistency to the appearance of, and the data in, the pages. This can 
be accomplished by the use of variables to hold definitions, such as colors and address¬ 
es, and by the use of user-defined functions to generate constant or similar sections of 
HTML, such as page headers and footers. Another objective is simplification. Again, 
shell functions can be used to consolidate much of the tedium of writing, say, an HTML 
table. A third objective is automation - having to go through as few steps as possible to 
get from one state to the next, in particular, from our source files to our final HTML 
documents. A fourth objective is mutability: we might want to create different versions 
of the same Web pages, for instance, for two separate servers at separate sites, make 
becomes useful for these latter two objectives. 
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Why Shell? 

I never really thought of the shell as a macro processor until 1 started using it in this 
context. But when you get down to it, the shell is very heavily built around string pro¬ 
cessing [2], which is what macro processors are all about, right? A line in a script is 
interpreted as a command only after variables and various other substitutions are inter¬ 
polated. A shell variable behaves much like a simple macro. And a shell user-defined 
function can be tantamount to a macro with parameters. Plus you get “all that good 
stuff,” the usual benefits of the shell: control structures, pipes, easy access to external 
commands, environment variables, etc. Personally, I find HTML somewhat tedious to 
write. Even comments are awkward, and are much easier in shell syntax. For me, the 
shell provides a much more comfortable (familiar?) style. 

Here’s a simple example of how you might use shell code to generate some HTML. A 
variable can be defined to hold a value or some HTML code: 

HAPPY=''<EM>Let's get happy!</EM>” 

and then that value can be written out at any following point in the shell code with: 
echo •'$HAPPY" 

Unless you’re planning on saying that a lot of times, this construct isn’t going to be ter¬ 
ribly productive. A more useful approach is to use a function, such as: 

enphasize () { 

echo ■’<EM>$*</EM>" 

} 

This function can then be invoked with: 
emphasize "Let's get happy!" 

The $* in the function body is replaced by the parameter(s) to the function, and the 
function is reusable with other text. And here’s an even more general form: 

tag_data() { 

_TAG="$1" 

shift 

echo "<$_TAG>$*</$_TAG>" 

} 

eirphasize () { 
tag_data EM 

} 

And if we were going to be saying it alot, then adding this might even make sense: 
get_happy() { 

eirphasize "Let's get happy!" 

} 

get_happy 

I hope you’re starting to get the idea. 

How the Processor Works 

One approach to using the shell as an HTML-generating macro processor is to write a 
master script consisting of your standard definitions (variables) and macros (func¬ 
tions), and then have the master script source (the shell’s period built-in command, 
see man sh) the files that define individual Web pages, producing a browser-ready 
HTML output file for each input file. 

So, to elucidate, each Web page is derived from a source file of shell code consisting 
largely of calls to the functions defined in the master script, and possibly redefinition of 
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some of the variables and/or functions. Unique features for each Web page are specified 
through parameters to functions, variable redefinitions, choice and order of function 
calls, and/or specific HTML coding. Optionally, local functions and other special pro¬ 
cessing can also be added to the source files. 

Here’s some code from a script named gen_Jitinl. sh that I used recently to help gener¬ 
ate a group of HTML files for a talk. The script begins with about 700 lines of variable 
and function definitions, option processing, etc. (Many of the variables can be overrid¬ 
den by variables in our HTML source files or by environment variables; the potential 
here for wrapper scripts is strong.) Finally, the loop below occurs at the end of the 
script. In it, we just process any arguments left on the command line, which should all 
be the names or basenames (suffix omitted) of HTML source files. (Actually, by this 
point, the arguments have already been scanned once to look for errors, and, if there 
were no arguments, a **-” indicating standard input would have been pushed onto the 
positional parameters.) Each input file is processed, and a corresponding HTML output 
file is produced: 

## 

## process (source) each input file 
## 

for FILE do 
case "$FILE" in 

# for stdin, make a tnp file and just process to stdout 
-) 

: ${UPDATE_DATE='date '+%e %B %Y''} 

HTML_FILE= " ???. $OOT_SUFFIX" 

[ "$QUIET" = 0 ] && echo "$PRC)G: processing stdin..." >&2 
cat > "$TMP_FILE" 

. "$TMP_FILE" # source it 

m -f "$TMP_FILE" 

/ / 

# otherwise, process and output to filename.html 
*) 

case "$FILE" in 
*.''$IN_SUFFIX") 

OUT_FILE='echo "$FILE” | 

sed 'S/.'"$IN_SUFFIX"''”$OUT_SUFFIX"'/'' 

/ » 

*) 

OUTJ’ILE="$FILE.$OUT_SUFFIX“ 

if [ ! -f "$FILE“ -a -f "$FIIiE.$IN_SUFFIX" ]; then 
FILE="$FILE.$IN_SUFFIX" 
fi 
esac 

HTML_FILE="$OOT_FILE" 

[ "$QUIET" = 0 ] && echo "$PROG: processing $FILE" >&2 

( 

UPDATE_DATE='get_update_date "$FILE”' 
case "$FILE" in 
*/*) 

. "$FILE" # source it 

/ # 

*) 

. ./"$FILE" # source it 

esac 

} > "$OUT„FILE" 
esac 
done 
exit 0 
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This loop could perhaps be simpler, but, as written, it can work as a filter processing 
from standard input to standard output, and it can handle filenames with or without a 
source file suffix. Some date processing also takes place so that a “Last updated:” time- 
stamp based on file modification time can be added to each page. (You know how hard 
it otherwise is to remember to manually update those dates!) The total length of this 
script might sound excessive, but it can be reused with minimal modification, and so 
the initial investment can pay off repeatedly. 

This script might be invoked with a command line like: 

•/gen_html.sh index parti part2 notes 
Here’s a very trivial example of what an HTML source file might look like: 


Got Q tool thars useful, 
unique, way cool? Please send a 
description to <Toolman@usenix.org>. 


## @(#) test.hsrc 
## 9/98, D.Singer 

begin_doc 

begin_head -t "This is a test of \'gen_html.sh"" 
end_head 

begin_jDody -bg " skin. jpg" 
do_break 

heading -C 1 "This Is A Large Title" 

heading -C 4 "and this a more subtle title" 

do__break 

do_hrule -s 6 2 

do_break 2 

begin_center 

begin_font -s +3 -c red 

eitphasize "Thanks for coming!" 

end__font 

end_center 

do_break 2 

do__hrule -s 6 2 

do_break 

do__last_update 

do_break 

do_footer 

end_body 

end_doc 

## end of hsrc file 

And here’s the resultant HTML output (slightly altered to conserve space): 
<HTML> 

<!— html document <www.cs.duke.edu/~des/workdir/test.html> —> 
<!— generated on Mon Sep 21 00:09:31 EOT 1998 —> 

<!— via ' gen_html. sh' —> 

<HEAD> 

<BASE HREF="http://www.cs.duke.edu/~des/workdir/"> 

<TITLE>This is a test of 'gen_html.sh'</TITLE> 

</HEAD> 

<BODY 

BGCOLOR="#fffffO" 

BACKGROUND="skin.jpg" 

TEXT="#000000" 

LINK="#339999" 

ALINK="#BBBB11" 

VLINK="#336060"> 

<BR> 

<H1 ALIGN=CENTER>This Is A Large Title</Hl> 

<H4 ALIGN=CENTER>and this a more subtle title</H4> 

<BR> 
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<HR SIZE=6><HR SIZE=6> 

<BR><BR> 

<CENTER> 

<FONT SIZE=+3 COL£)R=red> 

<EM>Thanks for coming!</EM> 

</FONT> 

</CENTER> 

<BR><BR> 

<HR SIZE=6><HR SIZE=6> 

<BR> 

<FONT SIZE=--1> 

Page last updated: 21 September 1998 
</FONT> 

<BR> 

<FONT SIZE=-1> 

URL: http://www.cs.duke.edu/~des/workdir/test.html 
</FONT> 

<BR> 

<FONT SIZE=-1> 

Copyright &copy; 1998, Daniel E. Singer. All rights reserved. 

</FONT> 

</BODY> 

</HTML> 

<!— end of generated document —> 

As you can see, the master script can also generate HTML comments for each Web page 
to provide standard identification blocks or other metadata. A more complete example 
would include tables and other snazzy features. Unfortunately, we don’t have the luxury 
here of the space that would be required. But I can’t resist at least showing you what 
some HTML source might look like for a table: 

begin_table -cols 2 -w 80% -C 
table_data -fs +2 -R ''<EM>Row 1" 

table_data -nobr “This table has two columns, 80% width, and is 
centered. The first column is right justified and has a bigger 
font. For the second column, we're forgoing putting a break 
between each line." 

table_data -fs +2 -R "<EM>Row 2" 
end_t abl e_r ow 

table_data -fs +2 -R "<EM>Row 3" 

table_data -nobr "The second row only had 1 column." 
end_table 

As the code shows, this table is self-documenting! It’s still a long way from WYSIWYG, 
but I like it better than the HTML that it will generate. See the end of this article for a 
URL for a sample gen_html. sh script; it will include the HTML-table-generating shell 
code. 

Other Benefits of the Shell Approach 

Using the shell as your HTML generator provides all of the features and power of the 
shell, and of course the whole toolbox of UNIX utilities (grep, sed, awk. Is, date, etc.) 
that comes along with it. An example of this is a situation where I use a flat database 
text file (lines with tab-separated fields) along with a supplementary script to produce 
multiple Web pages, each containing a list derived from the database, each sorted on a 
different key, and each providing hypertext links based on one of the fields. Believe me, 
this is much easier than maintaining these separate HTML pages by hand. For the situa¬ 
tion I have in mind, a list of alumni email addresses gets sorted by name and by class 
(that is, year). And a similar database exists for Web addresses. Here’s how it works. 

First, there’s the database (a text file) that looks like this (the names have been changed 
to protect the innocent): 
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# email-addrs.db 

# @(#) /u/des/public__html/sf/email-addrs.c3b 1.29 

Abbott, Gail gabb@mail.ced.net 1991 

Adams, Albert adman@fisheads.com 1976 

Adams, Fred adams@nunez.org 1982 

A supplementary script named cvt_addrs. sh reads the database, and then, depending 
on selected options, writes out the records in HTML form, sorted, with email addresses 
converted to mailto: links, and with section NAME anchors added. In the appropriate 
spot in the HTML source file, the line: 

./cvt_addrs.sh -f emai1-addrs.db 

invokes the script, and inserts the HTML data derived from the database sorted by last 
name. In another HTML source file, the same script is called with the addition of the -c 
option to get a sort by class. Additional code in each of these HTML source files gener¬ 
ates the jump lists used to go to a name anchor for a particular year or letter of the 
alphabet. For instance: 

echo ''<A" 

NEXTA=”-<A" 

for LETTER inABCDEFGHIJKLMNOPQRSTUVWXYZ; 
do 

[ "$LETTER" = "Z" ] && NEXTA= 

echo "HREF=\"email-addrs .ht:ml#$LETTER\ ''>$LETTER</A>$NEXTA" 
done 

This is much more concise and maintainable than the equivalent written-out HTML. 

Other Shells 

Of course, this could all be done with shells other than Bourne shell, such as ksh, bash, 
or even zsh. In fact some of these would probably make the job easier, as Bourne tends 
to be a bit archaic in some ways, and they are worth investigating. (Tm just too lazy.) I 
do tend to avoid the csh derivatives for scripting, but if you don’t want to take my 
advice on this one, well, let’s just say you’re on your own .... 

Until Next Time 

That’s it for the shell half of our discussion. To get the whole scoop, you’ll just have to 
bite your fingernails in anticipation until the February issue of ;login:y when we’ll 
explore how make plays an integral role in this process, providing the significant capa¬ 
bilities of automation and mutability. Please tune in next time. 

URLS: 


Of course, this could all be 
done with shells other than 
Bourne shell. . . 


<http://www.cs.duke.edu/~des/toolman.html> 

<ftp://ftp.cs.duke.edu/pub/des/scripts/gen_html/INDEX.html> 

Notes 

[ 1 ] I’ve even seen a recent article about using cpp (the c pre-processor) and make to do 
something very similar (Jim Fox. “Unity Among Web Pages” in SunExpert Magazine, 
August 1998, pp. 42-45.), though there are some substantial differences in style and con¬ 
tent between these two approaches. But, shoot, for us shell diehards, well, need I say 
more? 

[2] This is despite Bourne shell’s notable lack of built-in string processing functions. 

For many operations, it is necessary to engage external commands such as awk, sed, 
expr, etc. 
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You probably have a friend or relative who has expressed a desire to use the 
Web or communicate using email. They may want to shop for books online, 
monitor their financials, or search for health information. They might figure that 
the entry cost for equipment would be $1500 - $2500 - for many, a prohibi¬ 
tive amount. With some time, initiative, and willingness to take the path less 
traveled, however, a system capable of Web, email, and even document pro¬ 
cessing is possible for a small fraction of this price. 

The useful life of a computer in the business world is about three years. After that, cur¬ 
rent versions of mainstream office software run sluggishly on old hardware. The indus¬ 
try is geared toward getting companies to replace perfectly good hardware for the latest, 
fastest, biggest equipment. (Reminds me of the ‘60s and ‘70s, when many would replace 
their new cars every few years.) 

So here’s the plan: We’re going to find some older equipment and install Source Code 
UNIX software on it. Then we’ll configure it in a way to give your friend or relative the 
capabilities he or she needs. We’ll discuss how to connect to the Internet at an appro¬ 
priate price/capability level. 

Disclaimer: The ideas presented here are not meant to balance your personal 
time/money equation. Think of this proposal as an “exercise for the student” or as time 
invested in a hobby. (Otherwise, you might instead spend your energy on payable con¬ 
sulting and with the proceeds just buy an iMac outright for your friend.) 

Is This Heresy? 

For your friend who has more surplus time than cash, there are alternatives to buying 
that new, flashy, well-advertised, $2000 Wintel system. One reasonable option for some 
is the new $1300 Apple iMac. And the sub $1000 Wintel systems will probably be avail¬ 
able by Christmas. Source Code UNIX running on one-generation-old equipment is a 
good solution for many. You and 1 know that the Pentium-133 of 1995 runs UNIX just 
fine. For those who primarily surf the Web and use email, more power, large memories, 
and huge disks are just a waste. We may be concerned about putting the combination 
in the hands of a novice, but 1 surmise that keeping such a system running for a novice 
is about the same amount of work as keeping a new Windows 98 system running for 
the same person. Further, your friend won’t be faced with the constant upgrade costs 
for the OS, word processing, spreadsheets, and other applications. Once a UNIX system 
is set up, it should run trouble-free. It can be left on, ready to use any time like most 
household appliances. Your friend won’t be faced with the problems typical of Wintel 
systems - constant crashes and the periodic, time-consuming “reloading” the system. 

Yes, there is potentially tons to learn about a UNIX system but you are going to spoon 
feed the required pieces to the novice. People’s learning and coping skills are amazing - 
they can handle UNIX with about the same effort that doing the same tasks on other 
systems requires. 

Many applications in the Ports Collection probably will be useful to your friend. The 
October ;login: article, “Application Software: Ports and Packages” <www.boulderlabs.com> 
describes many of these programs. Some of the likely candidates include the general 
image manipulation software, GIMP (similar to Photoshop), drawing programs like 
TGIF; plotting packages such as GNUPLOT; spreadsheet software such as sc or oleo; 
editors, including the WYSIWYG Textcdit; and a large collection of games. 
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A small amount of experimenting with the window manager configuration should 
yield something that our novice will be happy with. (If necessary, you can configure 
fvwm to mimic Win 95.) Wliat about word processing? If they need word processing 
(and a printer), things become more complicated (as it does for commercial software.) 
Fortunately, several office packages run just fine on Linux or the BSD variants. 
StarOffice, Applix and Corel are the primary suppliers for this add-on, commercial 
software. They are reasonably priced; some are free from the Internet. 

Getting the Equipment 

First, let’s outline the assumptions. We’re trying to get a basic amount of functionality 
without spending lots of your friend’s money. They are going to use this system for 
personal use; none of it is business-critical. Make sure they could live with the inconve¬ 
nience of losing their system as a result of hardware failure. (You’ll teach them how to 
save their precious things on floppies.) It’s not a software-development machine or 
graphics workstation; these are beyond the scope of this article. Your friend will be 
patient while various things get ironed out. You have some spare time to build and to 
configure the system and, then, some time to help and advise. 

I suggest finding a low-end Pentium machine. Sure, there can be exceptions; you might 
happen to have some spare Alphas around that could run Linux, or you might have a 
working SparcStation-2 running SunOs4.x that is ready to be donated. But for most, 
let’s find that Pentium. Some of the 486s, given enough memory, will work fine, but if 
you don’t already have one to use, I wouldn’t bother with something that old. A 
Pentium-90 or Pentium-133 with 24-32 MB is a good choice. Here is where the initia¬ 
tive comes in; depending on the available budget, you or your friend might want to 
visit companies to obtain this hardware. A nice, friendly attitude at the right place and 
time could result in a gift. (After all, what’s the company going to do with machines 
that can no longer run Microsoft Office 98 ?) Maybe $50 would make their accountants 
happy. Larger companies sometimes sanction obsolete-equipment sales for employees 
and for the public. Here is an opportunity to negotiate price. 

You could look in the classified section, but often people think that because a system 
cost them $3,000 three years ago, it is worth half that today - False! Think 5%, certainly 
no more than 10%. Used computer stores have appropriate equipment. They tend to be 
expensive, but it’s worth a try. Department stores, OfficeMax, etc., periodically need to 
clear out unused obsolete models and display equipment. Hunt around. Deals abound 
for leftovers. I’m looking at a flier now (early October) that advertises a Cyrix 
133/32MB/2.1GB/33.6Fax/32xCD/l4”SVGA for $539. If the graphics card is acceptable, 
this is everything needed. For a little more, there is a K6 233MHz MMX, S3 ViRGE 
4MB video, 32MB/2.5GB/32xCD/33.6 system for $699. It still needs a monitor (any¬ 
where from an extra $100 to $1000), but it’s a very hot machine for Source Code UNIX 
- enough power even for most developers. 

The Internet offers resources for new equipment. I like <http://www.insight.com>. These 
guys pick up retailers’ and manufacturers’ surplus equipment for a song and try to 
unload it quickly for a profit. They have a number of Pentium II (233, 266, 333) sys¬ 
tems for under $1000. You’ll need to add a monitor. These systems don’t really qualify 
as “obsolete” hardware, but they might suit some people who have some money. Push 
their “specials” tab, then go to “inventory blowout.” Fill in the form with category 
“Computer Systems” and a maximum price. This will pop up a list of systems such as 
IBM Aptiva, Compaq Presario, HP Vectra, and others. Look at the technical specifica¬ 
tions and the stocking status. You’ll see choices in the $500 - $800 range. They also have 
an auction system for the adventuresome. Note the risks of buying off-brand or non- 
warranted equipment; if something breaks, you’re on your own. 
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The list of useful free or inex¬ 
pensive software that can run 
on these systems is endless. 
There are programs to balance 
checkbooks, track stocks, run 
Image scanners, and manipu¬ 
late audio. The games doom, 
chess, backgammon and others 
are all available. Once your 
friend handles the basics of 
surfing and emailing, you can 
enhance their software suite. 


Check out the “computers” section of <http://www.surplusdirect.com> for new and refur¬ 
bished equipment in all price ranges. Their new $549 Worldnet 7416 with a 233MHz 
K6 is a good candidate. These guys also have auctions. 

Other good places to shop include <http://www.streetprices.com> and 
<http://www.pricewatch.com>. My June ;login: article, “PC Hardware for Source Code 
UNIX” <http://www.boulderlabs.com>, lists many other Web sites. 

Most Pentium, AMD or Cyrix hardware will work fine with Source Code UNIX. As 1 
mentioned in the June article, the problem areas are mostly cheap, off-brand video 
cards and some Plug-and-Play devices. Some early research or try-before-buy attitude 
will save later headaches. 

Loading and Configuring the System for Basic Capabilities 

Get your software distribution CDs ready. The favorite supplier for Linux is RedHat 5.1 
for $50. For those preferring a BSD UNIX, consider FreeBSD 2.2.7 (or 2.2.8 by the time 
this is published) for $40. The main Web locations for Source Code UNIX are (you'll 
need software from only one of these): <http://www.linux.org>, <http://www.infomagic.com>, 
<http://www.redhat.com>, <http://www.caldera.com>, <http://www.freebsd.org>, 

<http://www.netbsd.org>, and <http://www.openbsd.org>. 

My article in August ;logiti:, “Loading Source Code UNIX,” goes over the general opera¬ 
tions that are needed to bring up the system. This section augments it with material 
oriented towards getting certain capabilities for the novice. The first issue to handle is: 
What “look and feel” do we want for our friend? If the person has been exposed to 
Windows, it may be best to try to mimic that GUI. You can get the “Explorer” look and 
feel with programs such as xfm. Hackers have munged the fvMn2 window manager to 
look like Windows 95. Lots of the idioms, such as window frames and task bars, are 
present. There are file managers that allow drag-and-drop operations. I don't think it's 
very important to tightly copy the Windows 95 environment, but this issue is open for 
discussion and experimentation. 

For the novice who hasn't been “preconditioned,” there are choices. Fvwm and ctwm are 
both good window managers that can handle everything a novice needs. You, the 
instructor, have the opportunity to teach whatever you believe in. For example, 1 prefer 
windows that activate when the cursor is placed in them versus the click-to-type kind. 1 
hate “autoraise” windows, and 1 program FI and F2 to raise or lower the window that 
the cursor is in. 1 would avoid features that can get a person lost, such as a virtual win¬ 
dow manager that allows you to scroll to empty desktops. The aesthetic decisions go on 
and on - you get the idea. This is the easy stuff. How are you going to teach file manip¬ 
ulation? Drag and drop for everything or possibly some command line operations? 

How will the user back up precious files to floppy? Sorry, I don't have all the answers - 
it depends a lot on the user. 

How will they browse the Net? The current versions of Netscape are memory pigs, but 
they probably represent the best option. I'd stick with the slightly smaller Netscape 
Navigator that doesn’t have as much bloatware as Netscape Communicator, unless you 
want the mail system and a news reader all in one. The standard versions come with 
40-bit encryption. Some financial institutions (<http://www.vanguard.com> for example) 
require the much stronger 128-bit encryption to access customers' data. Find out what 
your friend intends to browse to learn if the US-limited, strong encryption version is 
necessary. 

What mail system makes sense for a novice? 1 know of many beginners who do just fine 
with Pine. I swear by exmh and don’t think it would be too hard for a smart, noncom¬ 
puter person. Lots of people like using the mail facility in Netscape. 
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What editor will you set up? I think there are many choices better than vi. Consider 
Textedit, Jot and other modeless editors. The office packages discussed in the next sec¬ 
tion offer other choices. 

You probably should set up your friend as a normal user; I think you would regret 
starting them as root. For operations for which they need more privileges, give them 
the sudo command or make some suid programs. But don't flood them with too 
much superfluous information too soon. 

You probably want their login scripts to start a window manager that has icons for mail 
and Netscape. Other processes such as xclock and calendar might also be useful. 

You should “know your audience.” You decide how much or how little they can handle. 
There are individuals that will never feel comfortable with computers and software - 
even Macintoshes. Maybe you won't want to get involved with such cases. Others, like 
my 12-year-old niece, can handle just about anything. When the family Wintel machine 
crashed and burned, she had no hesitation wiping the disk and reloading. If this non¬ 
geek girl can get that far with Wintel, she won't have any problem with a “real” operat¬ 
ing system. 

Connecting to the Internet 

Internet Service Providers (ISPs) are everywhere. Some advertise heavily, others are dis¬ 
covered by word of mouth. Most ISPs offer part-time dial-up connectivity (10-15 
hours) for about $10 per month and a bigger plan or unlimited usage for $20 or so a 
month. In general, I would suggest using Point to Point Protocol (PPP). Just about 
every ISP can deals with PPP, and the protocol can handle dynamically assigned IP 
addresses. How does one choose a service provider? I would evaluate the following fac¬ 
tors as a function of the price: 

■ How much technical support is available? 

■ Will they work with you even though you don't have Windows 95? 

■ Is it a local call? 

■ How much time do you get per month? 

■ What is the incremental charge when you exceed your quota? 

■ Is the service reliable, or does it often go up and down? 

■ How available are the dial-in modems when you would be using the service? 

■ Is the ISP machine reasonably loaded in terms of the number of users and the band¬ 
width available to the Internet? 

■ Can you get a reasonable email address like <robert@clark.net> or must you live with 
something obscure like <rbh4782@aol.com>? 

■ What dialin speeds are offered? 

PPP Setup 

Modems, IP addresses, routing, and name services might be the most difficult and frus¬ 
trating part of the whole ordeal. You have to know a little about a lot of stuff to get it 
all working. Here's where the help services of a good ISP can make a difference. They 
might have good written instructions or patient, competent technical support people. 
Before you try connecting, you must have several pieces of information: 

■ the ISP modem phone number 
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m the account username and password 

■ possibly miscellaneous CHAT scripts 

■ the IP address of the nameserver 

■ the IP address that your ISP wants you to use. 

PPP has some black magic in it. With luck, you’ll get IP connectivity with no problem. 
Otherwise you’ll need to try things, read manuals and FAQs, and get help. 

The Connection 
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Since we are talking cheap here, you probably won’t be setting up frame relay or ISDN. 
For most novices, basic modem speeds of 28.8K or 33.6K will be just fine. But if your 
ISP has 56K, you have a capable modem (they are now called v.90), and the phone lines 
between you are capable if it, you might as well have the faster speed. (Note that a large 
percentage of people cannot use 56K because of the Telco infrastructure.) In my area 
(US West territory), ADSL is making a big splash. For about $65 per month, you get 
your regular voice line and Internet access at speeds of 256K and up. You have some sig¬ 
nificant up-front costs, but thereafter you’ve got a great setup. 

Word Processing and Other Applications 

The big stumbling block for UNIX has been word processing or compatibility with the 
rest of the word-processing world. I used to think that if you wanted Microsoft applica¬ 
tion capability under UNIX, you had to run an emulator such as the commercial, 
expensive SoftWindows. Then you had also to buy the Microsoft applications. 1 found 
the whole combination was marginal. lust recently I discovered StarOffice 
<http;//www.stardivision.com> that gives you a word processor, a spreadsheet and other 
applications that have the “look and feel” of Microsoft Word and Excel. (Thank good¬ 
ness the look and feel lawsuit didn’t stand!) These applications not only mimic the 
expensive commercial ones, they also allow full interchange of documents and material 
with the commercial ones. So you can receive a Word document, modify it and send it 
back in Word format. The Word and Excel products are full-featured; if you can do it 
under Microsoft, you can do it under StarOffice. The PowerPoint like application cur¬ 
rently can only read Microsoft’s format. They hope by the end of the year to be writing 
that format too. StarDivision claims: “StarOffice guarantees the direct collaboration 
with Microsoft Office, without requiring any additional measures.” Now the best part; a 
non-commercial, personal use version is free from the Internet. If you want their CD set 
and printed manuals, it’s only $40 (this saves a 60MB Internet download.) 

Applix <http://www.applix.com> offers Applixware, which gives you word processing and 
spreadsheets, but doesn’t try to look exactly like Microsoft. It has filters to deal with the 
Microsoft formats. Applixware Office Suite 4.3.7 comes with word processor, spread¬ 
sheet, presentation graphics, email, and HTML authoring for $99.95. 

OpenLinux from Caldera ships with the free graphical KDE desktop environment, 
StarOffice 4.0 suite, Netscape Communicator, and the Linux 2.0.35 kernel for $59. 

WordPerfect is available for Linux and the BSDs. It represents a viable option to Word 
and is the mainstay of the legal profession. 

LyX is a front-end for the document processing system LaTeX. It has lots of WYSIWYG 
features that bring the system closer to its word-processing competitors, while preserv¬ 
ing the amazing flexibility of raw LaTeX. 

People doing word processing are going to want a printer - probably an inexpensive 
ink-jet printer rather than an easier-to-deal-with and more expensive Postscript printer. 
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It used to be hard to drive these couple-hundred-dollar printers from UNIX, but things 
are rapidly improving. The Ghostscript system can print to a wide variety of low-end 
printers, including the HP Inkjets, the Cannon Bubblejets, Epsons, and others. See 
<http.7/www.cs.wisc.edu/~ghost/printer.html> for a list of models. 

The list of useful free or inexpensive software that can run on these systems is endless. 
There are programs to balance checkbooks, track stocks, run image scanners, and 
manipulate audio. The games doom, chess, backgammon and others are all available. 
Once your friend handles the basics of surfing and emailing, you can enhance their 
software suite. 

Conclusion 

In today’s world, the people without Web access and email are at a disadvantage. Plenty 
of people on tight budgets cannot afford to spend a grand or so on nonessential stuff. 
Even if you have significant disposable income and could give a computer system, a 
large circle of friends or too many siblings, in-laws, cousins, etc. could bankrupt you. 
Alternatively, you might find it challenging and fun to build a useful resource for peo¬ 
ple you care about. Maybe I’ve given you some ideas for your holiday list. 

Thanks to Tom Poindexter, Rob Kolstad, and Steve Gaede. 



torn money and the 
PGP web of trust 


Legitimacy and trust are perhaps the most complicated aspects of PGP (Pretty 
Good Privacy). The trust model used by PGP assumes that trust starts with 
bilateral arrangements (key signing) and grows organically to produce a decen¬ 
tralized “web” known as the “Web of Trust.” Decentralization is advantageous 
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in that it foregoes the need for any central authority, yet the model as it stands 
does not scale well in a large, open community. Torn Money has been designed 
as an authentication service primarily to facilitate the introduction of new users 
to the Web of Trust and also as a means of enhancing connectivity within the 
existing web. 
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Torn Money is a follow-up to the AUUG’s PGP Key Signing Service, which, in essence, 
seeks to maintain and support PGP’s decentralized trust model. 

Background 

PGP is a publicly, and internationally, available privacy program. Essentially, it uses 
public key cryptographic techniques to allow messages to be exchanged between people 
across public networks while protecting the privacy of the contents and guaranteeing 
authenticity of the sender. 
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Traditionally, one of the problems with cryptographic systems was “key management.” 
The key is the secret value that allows information to be encoded and/or decoded. Prior 
to the development of public key cryptography, the key had to be securely exchanged 
between parties before they could communicate. Public key systems are designed such 
that two separate keys are used, one of which can be made public (like a telephone 
number) while the other is kept secure by the owner (like the telephone itself). In light 
of this development, it would appear that the problem of key management has been 
solved. 

Unfortunately, this is not the case. Key management is undeniably easier using public 
key systems, but the question now becomes one of authentication. How do you know, 
for sure, that the person you are sending a secret message to is really the person he or 
she claim to be? I could easily get a telephone connected in another name and sit back, 
waiting for phone calls intended for another person of that name. 

One solution to the problem is to introduce the notion of “trusted parties,” that is, peo¬ 
ple whom you trust to introduce (and therefore authenticate) other parties to you. 
Using the telephone analogy, you would say secret things on the phone only if someone 
you trust had given you the telephone number, not if you had just looked it up in the 
phone book. This is what the PGP documentation refers to as the Web of Trust. Its 
structure is likened to that of a web because each party involved, trusted by you, can 
introduce other parties whom you may or may not already know. 

Another possible solution is the use of Certification Authorities, thereby enforcing a 
hierarchical structure on the Web of Trust. What this means is that any public key you 
acquire must now come with a list of certificates. For example, J. Smith s public key 
might come with a certificate from Widgets, Inc., stating that he works for them. In 
order to establish their authenticity. Widgets, Inc. would also require a certificate from 
someone asserting that it is a Delaware corporation. To authenticate this, the state of 
Delaware would need a certificate to verify it was really what it claimed to be, and so 
on. Eventually, the regression must stop, with a certificate being issued by some 
omnipresent authority (which, at the moment, is RSA Data Security, Inc.). 

Both schemes have flaws. The major problem with the Web of Trust is that it has to be 
big and well connected before it becomes useful, but the Certification Authority 
approach assumes the sort of control that is often the reason the parties wanted to 
communicate privately in the first place. 

(The above is intended to be an absolutely minimal explanation of the concepts of 
public key cryptography and key management. If the concepts are not yet clear, the 
PGP documentation, which you should eventually read, explains it in more detail.) 

Torn Money and the PGP Key Signing Service 

In an attempt to expand the Web of Trust, AUUG set up a PGP Key Signing Service in 
which it acted as an introducer for PGP keys. By virtue of the conferences it held, 

AUUG was in a position to physically meet with people, verify their identity, and then 
issue key signatures attesting to their identity. The high public profile of the organiza¬ 
tion meant that key verification wasn’t difficult, and as the procedures for the key-sign¬ 
ing were made public, it was easy to decide what level of trust to place in the authentic¬ 
ity of a key signed by AUUG. However, the service was beginning to introduce a hierar¬ 
chy into the Web of Trust, with AUUG inadvertently taking on the role of a 
Certification Authority. The implications of this brought the service to an end, because 
it was no longer conforming to the PGP trust model. However, the service had one very 
innovative feature: it did not require people to have their key ready in advance. 
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“Torn Money” has been designed in the same vein as the Key Signing Service, with its 
main aim to facilitate PGP key signing. This new service avoids the problems that the 
Key Signing Service was beginning to encounter while managing to preserve the favor¬ 
able features - namely, it still allows the verification of those who have not prepared 
their keys in advance. The inspiration behind Torn Money comes from old spy films, 
where the possession of a significant half of a torn banknote established a person’s 
identity. The beauty of such a concept is that it no longer requires an “authority” such 
as AUUG to oversee the key-signing, the notion of the “torn” banknote means that any 
two parties can be involved and still effectively identify each other at a later date. 

Introduction to Torn Money 

PGP signing can occur whenever one interested party meets with another (conferences 
such as those hosted by AUUG or USENIX are a common forum for such an activity). 
People wishing to have their keys signed provide acceptable proof of identity together 
with their PGP fingerprint to the person or persons they wish to have sign their key. 
Their public key can then later be retrieved for signing from a key server or sent via 
email, with the supplied fingerprint providing verification of the key’s authenticity. 
However, this kind of key signing is meaningful only if the interested parties already 
have PGP keys generated and their fingerprints with them. This is not always the case. 

Torn Money sidesteps this issue by providing a way in which interested parties can suc¬ 
cessfully identify each other at a later date. Conceptually, this means that, upon meet¬ 
ing, interested parties will establish their identities as before and then obtain a “secret.” 
The possession of this secret is what enables secure future communication. With this 
in place, those who are unprepared now have the opportunity to create a PGP key at 
some later time and then communicate the required details to those parties from which 
they obtained their secret. By revealing the secret they were given, they are able to prove 
their identity, thus validating their key for signing. 

Although this scheme makes it conceptually viable for two unprepared parties to trade 
details. Torn Money’s primary function is to introduce newcomers to the Web of Trust 
and enhance connectivity. It is therefore essential that one of the parties involved 
already belong to the Web of Trust so that his or her signature will act to initiate a new¬ 
comer. This person, call this an “expert user,” will effectively become the “owner” of the 
Torn Money. It is this person’s responsibility to generate and distribute the Torn 
Money, but he or she is in no way to be considered an “authority.” To such effect, the 
newcomer is well advised to participate in the Torn Money scheme with as many expert 
users as possible. 

Definition of Torn Money 

Torn Money borrows its form from that of a banknote. It is simply a piece of paper 
containing pairs of related secrets (which function something like a banknote’s serial 
number). Upon generating a piece of Torn Money, the expert user will be required to 
enter name, email address, PGP Key ID and fingerprint, and the number of newcomers 
he or she wishes to sign keys for. This information is required to facilitate future com¬ 
munication between the owner of the Torn Money and the recipients. 

The generated piece of Torn Money will contain the owner’s name and PGP fingerprint 
at the top, as well as a sentence comprising eight four-letter words - the secret. Next, 
there is a blank table of n rows, where n is the number of newcomer keys the owner 
elected to sign. This is left blank so that the expert user can note down the name, email 
address, and identification information (optional) of anyone wishing to participate. 
Lastly, the remainder of the document is divided into n sections, designed to be “torn” 
off by the owner and distributed among the participants. Each section contains the 

December 1998 ;login: 


"Torn Money" has been 
designed in the same vein 
as the Key Signing 
Service, with its main aim 
to facilitate PGP key 
signing. 



63 


FEATURES 







Note: The use of Tom 
Money is in no way 
restricted to 
newcomer/expert user 
pairs. /Is our overall 
objective is to increase 
connectivity within the 
Web of Trust, established 
users of PGP who may 
arrive at a gathering 
ill-equipped for key signing 
are also encouraged to use 
Torn Money 


name of the expert user, his email address, PGP key ID and fingerprint, the Web 
address of the Torn Money Web site, and eight four-letter words - the participant’s 
secret. (See Appendix for a sample of Torn Money). 

After verifying a newcomer’s identity, the expert user notes their details in a row in the 
table and gives him the tear-off section corresponding to his row number. This piece of 
Torn Money should be kept safe and it is now the only existing link between the expert 
user’s identification information and the new user. For security reasons, it is also vital 
that no one else has access to the Torn Money, as it contains the new user’s secret. 

Once the newcomer has generated his own PGP key, he should send email to the expert 
user(s) for whom he has Torn Money. To be secure, the email should be encrypted 
using the expert user’s PGP key (obtained either from the expert user or a key server 
and verified with the fingerprint of the newcomer’s half of the Torn Money), and 
signed using the newcomer’s PGP keys in order to prove ownership. The content of this 
mail should comprise the new user’s PGP public keys itself and the secret eight four- 
letter words from the Torn Money. 

Upon receiving this message, the expert user must verify the secret received before sign¬ 
ing the new key. The new user’s secret is derived from a combination of the expert 
user’s secret, her row number in the table on the expert’s half of the Torn Money, and 
the expert’s user’s name. Thus, the expert user must provide these details exactly to the 
Torn Money verification program to authenticate the contents of the email message. 
Once this has been achieved, the expert user can sign the new user’s key and return it. 

Note: The use of Torn Money is in no way restricted to newcomer/expert user pairs. As 
our overall objective is to increase connectivity within the Web of Trust, established 
users of PGP who may arrive at a gathering ill-equipped for key signing are also 
encouraged to use Torn Money. 

Torn Money Generation and Verification 

Torn Money can be generated in two ways: either by using the Web interface at the 
USENIX Web site, or by downloading the source for it and generating it on your own 
computer. The same option applies to the verification of the procedure - a Web inter¬ 
face is available, and the source for it comes as part of the download for the Torn 
Money program. 


User Support 

Once the Torn Money project is complete, full documentation and procedures for use 
will be made available from the USENIX Web site. At this point in time we envision the 
users of Torn Money to comprise three distinct groups: new users of PGP seeking con¬ 
nection to the Web of Trust, expert users willing to certify new users, and people wish¬ 
ing to advertise gatherings (e.g., conferences, seminars, etc.) where PGP key-signing or 
exchange of Torn Money can occur. As such, a series of pages will be dedicated to each 
group. 


64 


Vol. 23. No. 6 ;login 





newcomers Instruction Page 

In support of new users of PGP and Torn Money, a series of help pages will be made 
available and the Web addresses included on their piece of Torn Money. These pages 
will include information on PGP and trust, the function of Torn Money and its usage, 
links to key servers, and the details of any gatherings at which the exchange of Torn 
Money can occur. 

Expert Users Instruction and Generation Page 

A set of pages will also be aimed at established users of PGP who wish to generate their 
own pieces of Torn Money. These pages will include information on the function of 
Torn Money and its usage as applicable to an expert user, as well as details on how to 
generate Torn Money and how to verify responses from recipients. The date and loca¬ 
tion of any gatherings at which the exchange of Torn Money can occur will be made 
available, and expert users intending to engage in key-signing (and specifically the dis¬ 
tribution of Torn Money) will be given the option to register their attendance at specif¬ 
ic functions. 

Organizer's Page 

As part of the Torn Money key-signing service, support will be given to functions and 
gatherings at which key signing can occur. This support will be provided through a 
series of pages on the USENIX Web site that will allow organizers to register their func¬ 
tions as forums for PGP key-signing and the distribution of Torn Mone)^ The time, 
date, and location of the function will be made publicly available so that expert users 
may indicate their attendance and hence their willingness to certify new users and new¬ 
comers seeking an introduction to the Web of Trust may see when they next have the 
opportunity to be certified. 

All feedback, questions and concerns regarding Torn Money can be directed to Greg 
Rose and/or leanette McLeod. Over time appropriate FAQs will be compiled and post¬ 
ed to the Web site and Torn Money will be revised to better meet user needs. 

Concluding Remarks 

Successful world wide use of PGP depends on a widespread, well-connected Web of 
Trust. Torn Money has been designed with this goal in mind. The project is due for 
complciion sometime this fall, and the Web pages discussed in this article will be made 
available from the USENIX Web site <http://www.usenix.org>. Meanwhile, any feedback on 
the project is welcome, and Torn Money is available for trial usage on request. 
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Appendix 

TORN MONEY FOR leanette McLeod 

Kev Fingerprint: 

Verification: 

IB DE 98 8F C8 49 05 4B 82 56 DD DA 67 4E FD BO 

real yawn ntis warm winy peel date rate 

No. Name 

Email Address Id Information (optional) 

0 



2 


3 


4 


0. Name: 

Email: 

Jeanette McLeod 
<jmcleod@qualcomm.com> 


Key ID: 2C500945 

Public Key Fingerprint: IB DE 98 8F C8 49 05 4B 82 56 DD DA 67 4E FD BO 
Verification: quit list burg mesh dare jane afro grad 


Help: 

1. Name: 

Email: 

<http://www.USENIX.org/tornmoney/newcomer.html> 

Jeanette McLeod 
<jmcleod@qualcomm.com> 


Key ID: 2C500945 

Public Key Fingerprint: IB DE 98 8F C8 49 05 4B 82 56 DD DA 67 4E FD BO 
Verification: marc oral tick voss mimi cosh toby pure 


Help: 

2. Name: 

Email: 

<http://www.USENIX.org/tornmoney/newcomer.html> 

Jeanette McLeod 
<jmcleod@qualcomm.com> 


Key ID: 2C500945 

Public Key Fingerprint: IB DE 98 8F C8 49 05 4B 82 56 DD DA 67 4E FD BO 
Verification: boat pike amok fast abbe told held coon 


Help: 

<http://www.USENIX.org/tornmoney/newcomer.html> 

3. Name: 

Email: 

Key ID: 

Jeanette McLeod 
<jmcleod@qualcomm.com> 

2C500945 


Public Key Fingerprint: 1B DE 98 8F C8 49 05 4B 82 56 DD DA 67 4E FD BO 
Verification: scot cord iris lure doff fuel lazy quad 


Help: 

<http://www.USENIX.org/tornmoney/newcomer.html> 

4. Name: 

Email: 

Key ID: 

Jeanette McLeod 
<jmcleod@qualcomm.com> 

2C500945 


Public Key Fingerprint: 1B DE 98 8F C8 49 05 4B 82 56 DD DA 67 4E FD BO 
Verification: anne duke lamp mock blat lark gawk lair 

Help:^ <http://wmUSEM 
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using |ava 

Security Outside the JVM 


In a previous ;login: article (“Is Java Secure?” August 1998) I presented some 
issues related to security inside the JVM. 

The focus of this article is security outside the JVM. Specifically, 1 will examine the Java 
Cryptography Architecture (JCA), which is in the package “java.security” of the 
jdkl.l.’^ release. I’ll examine the design of the JCA and present a sample Message Digest 
(MD5) example. 

The JCA is an interface for application developers who wish to use the cryptographic 
functionality and for those who wish to provide cryptographic functionality; the latter 
are called “providers.” 

The security package is based on public key cryptography in which each party partici¬ 
pating in a secret conversation has a public key and a private key. The cryptographic 
functionality refers to message digests, signing messages, public key certification, and 
many other functions. 



T 

by Prithvi Rao 

Prithvi Rao is the founder of 
Kiwilabs, which specializes 
in software engineering 
methodology and Java train¬ 
ing. He has worked on the 
development of the MACH OS 
and a real-time version of 
MACH, and he holds two 
patents resulting from his 
work on mobile robots. 
<prithvi+@kiwilabs.com> 



How the JVM and JCA Work Together 

Java environments can take advantage of cryptographic functionality by attaching to a 
class file of an applet, the digital signature of the person who wrote the applet. The 
browser that downloads the applet can examine the digital signature and enforce some 
policy regarding the “trustability” of the applet. The JDK 1.1 appletviewer and Hot Java 
browser will support signed applets. 

Regardless of how Java-enabled environments can make use of JCA, it is clear that 
applications such as electronic commerce (and other transaction-based applications) 
can make good use of JCA. 

Message Digests 

As the name suggests, a message digest is a condensed representation of some data. It is 
a representation in the sense that it is very difficult (not impossible) to find another 
message that has the same digest. Message digests are commonly provided in most 
cryptographic software, and so it makes sense to examine it here. 

Many algorithms can be applied to provide message digest capability. Some well-known 
algorithms are MD2, MD5, SHA (signature hash algorithm). Using the JDK security 
package, it is possible to choose any of these. Naturally, the choice is made by the user 
on the basis of the stringent security requirements of the application. 

JCA Design 

JCA has been designed with both “users” and “providers” in mind. For instance: 

Users (who need cryptographic support): 

■ can think in terms of concepts 

■ can request a particular functionality and algorithm 

■ can specify a particular implementation. 

So if an MD5 algorithm is available from two different providers, the application devel¬ 
oper can specify not only that they wish to use the MD5 algorithm, but also that it 
should be a specific provider’s implementation. 

Providers (those who provide cryptographic functionality): 

■ implement a set of security services 
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m can coexist; a particular functionality can be provided by more than one provider. 

■ can work together. 

Providers can use the basic classes to provide cryptographic functionality. The same 
functionality can be provided by various providers, and they can work together. For 
example, support for PGP (Pretty Good Privacy) keys from one provider can work with 
keys of another provider. This is significant when you consider that code reusability 
might result in using classes that are not using PGP keys from the same provider (yet 
another example of why understanding interoperability is important in a different con¬ 
text). Another example is the ability to take the MD5 output of one provider and have 
it compared with MD5 implementation of another provider. 

JCA Classes 

The classes that are part of the java.security package consist of a collection of core 
classes. These core classes are referred to as engines because they encapsulate the actual 
mechanism that does the work. 

Each class provides a particular functionality. Some example classes are: 

public abstract class MessageDigestt....} 
public abstract class Signature{....} 

The file MessageDigest. java contains the class definition for message digests. 

Another core class is Signature and is used for electronic signing of data. All of these 
core classes are abstract classes. In other words they encapsulate a concept rather than a 
specific algorithm. 

Core classes must be subclassed for each implementation of a particular algorithm: 

public class MD5 extends MessageDigest{...} 
public class SPiA extends MessageDigest{. . .} 
public class SHAWithDSA extends Signature!...} 

A provider wishing to provide a particular functionality must do so by first extending 
the core class for that functionality and then providing an implementation. This is why 
these abstract classes are called “engines.” The subclass SHA, for example, will define a 
method that does the work of SHA, and similarly SHAWithDSA will contain a method 
which does the work of computing the hash using the SHA algorithm and then encrypt¬ 
ing the computed hash using the DSA (Digital Signature Algorithm) algorithm. 

Users who wish to use these implementations instantiate a class of particular provider: 

MessageDigest md = MessageDigest.getInstance{"MDS"); 

MessageDigest md = MessageDigest .getinstance ("MDS", ''NSA'*); 

Signature sig = Signature.getinstance("DSA", "PrettyGoodSecurity"); 

Each of the core classes contains a static method called getinstance which searches 
for and returns an instance of the engine requested. So in the first example, md is an 
instance of MDS provided by the “default” provider. The second is an instance of MDS 
provided by “NSA.” The third is an example in which sig is an instance of the DSA 
algorithm by a provider called “Pretty Good Security.” There is a configuration file in 
which you specify the availability of providers. 

JCA: An MDS Example 

Let s take a look at an MDS application. Here we use a provider’s implementation. 

inport j ava.io.*; 
import j ava.security.*; 
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The second import must be included because it is not loaded automatically. 

public class MDSTest 
{ 

public static void main(String[] args) 

{ 

byte[] msg, msgSxmDigest; 

Msg is the buffer for the message for which we want to compute the digest. MsgSunDigest is 
the buffer which will eventually contain the MD5 digest. 

File f; 

FileInputStream fis; 

MessageDigest mdSSun; 

MdSSun is the instance of the MD5 digest class. Since it is a subclass of MessageDigest this 
declaration is ok. 

int c, nbytes, len; 
if(args.length < 1) 

{ 

System,out.println( "Usage: java <file to digest>"); 

System.exit (1) ; 

} 

try 

{ 

Have to put this within a try because many of the methods below throw exceptions. 

mdSSun = MessageDigest. getinstance ("MDS") ; 

/ / mdSSun = MessageDigest. getinstance ("MD5", "SUN") ; 

This is where the program creates an instance of the message digest class which implements 
the MDS algorithm. The first example asks for any implementation of MD5, and the sec¬ 
ond requests SUN*s implementation^ which is actually also the default. 

The reason to use getinstance rather than instantiating a class using *'new”is that your 
application might be running on a host in an environment about which you know very lit¬ 
tle. In order to instantiate a class as ''new MD5(ff it is necessary to know the package from 
which it camcy and this is not always possible. The danger in requesting a particular 
provider is that the program will throw an exception if that provider's algorithm is not 
available. You can always set up exception handlers to try other "well known” providers if 
the provider of choice throws an UnknownProviderExceptior}. 

f = new File(args[0]); 
msg = new byte[len = (int) f.lenght {) ] ; 
fis = new FileInputStream(f) ; 
if ((nbytes = fis.read(msg)) 1= len) 
throw new IOException(len + "unavailable."); 
fis.close{); 

Open and read the file containing the message for which we wish to compute the digest. 
mdSSun.update(msg); 

Update is an abstract method of the class "security.MessageDigest.” It takes a buffer with 
bytes from the original message and supplies it to the MDS engine. Here we supply the 
entire message to update. 

msgSunDigest = mdSSun.digest(); 
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The security package is 
very intuitive and simple to 
use. Once again, this is a 


Digest is another abstract method of'security.MessgeDigesC This method returns the 
(MD5) digest of the original message. The MD5 algorithms always produce digests that are 
128 bits (16 bytes) long. 

System.out.printIn(mdSSun. toString() ) ; 

} 

} 

Print out the data. 


testimony to Sun’s desire 
to create an easy, 
extensible, and strong 
security architecture. 


Running the Program 

To run the program try the following steps: 

unix> javac -g MD5Test 

unix> java MD%test <naine of text file> 

The output will show the provider s name, the MD5 hash value and the output of the 
original text file. 

Conclusion 

The security package is very intuitive and simple to use. Once again, this is a testimony 
to Suns desire to create an easy, extensible, and strong security architecture. 

Future articles in this series will include an example on how to be a provider and will 
examine the Java Cryptographic Extensions (JCE). 

Readers wishing to get source for the example can send email to the author. 
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musings 

“Make it so.” With these three words, and perhaps only ten minutes before the 
end of the show, Picard, a now legendary manager (as well as Starfleet cap¬ 
tain), sets his crew scurrying into motion. Each crew member has provided sug¬ 
gestions, and Picard has weighed their possible consequences, and made his 
decision. Well within the assigned time limit, they solve whatever technical 
problems they had, and peace in the quadrant is again assured. 

If only the real world worked so well. 

I have been waving my magic wand for years now, to little effect. Perhaps global warm¬ 
ing can be blamed on me (all the hot air). Or, perhaps I forgot the magic words: “Make 
it so.” Maybe it s the lack of enough venture capital funding? No, just kidding. I have 
heard from several people what a nightmare quarterly reports can be (unless you are 
already quite profitable). 

And then, someone said to me, “Why don’t you quit waving that thing around, and 
open your eyes to what already exists?” Well, what a fine idea. 

The first thing I noticed was the proliferation of free UNIX. The UNIX operating sys¬ 
tem was once enslaved, the intellectual property of a very large networking company, 
the one with the death star logo. You know the one. A very small (at the time) network¬ 
ing company, with strong roots in UNIX and UUCP, decided it was time to take the 
bull by the horns, and announced that they had created an unencumbered version of 
UNIX. In order to do this, they had to replace the parts of the Berkeley UNIX kernel 
that were owned by the big company. Some programmers with no prior knowledge (in 
particular. Bill lolitz) were hired to produce the missing pieces. 

Virtual Memory 

Memory management was one of the more critical, and arcane, missing pieces. By cre¬ 
ating and publishing (in Dr. Dobbs) this information, UNIX became free. Well, almost. 
To the bitter end, the large company maintained that it had protected its intellectual 
property rights. As proof, they could point to the number of companies that had been 
forced to change the last four digits of their phone numbers from 8649 (UNIX) to 
something else. The large company’s lawyers would also send yearly letters out to any¬ 
one who had misused the adjective “UNIX.” That is, you could not publish something 
that read “UNIX,” but could say “the UNIX operating system.” 

The argument grew quite heated, even as the lawyers became richer and the small com¬ 
pany poorer. Fortunately, the large company was not totally humorless - they stipulated 
that anyone who had ever seen UNIX source code was “contaminated.” That is, anyone 
who had worked with the large company’s source code would forever be in thrall and 
unable to produce code that had not been influenced by the experience. Many people 
in the UNIX community responded by wearing badges labeling themselves as “mentally 
contaminated.” 

Eventually, it was determined that out of thousands of source files, only four could be 
said to be in dispute. The large company, AT&T, lost, and the rest of us, and UUNET 
and BSDI, won. BSDI still sells and supports 4.4 BSD UNIX, and three other organiza¬ 
tions support free versions of BSD (OpenBSD <http://www.openbsd.org>, FreeBSD 
<http://www.freebsd.org>, and NetBSD <http://www.netbsd.org>). 

Around about the same time, Linus Torvalds, a student in Finland, began working on 
task switching and the 80386 protected memory mode, writing in assembly. He was 
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The roots of UNIX go back 
almost 30 years. Although 
Linux is a “new” operating 
system, it is also based on 
UNIX. What about 
something completely 
different, starting from 
scratch? Like BeOS. 


inspired by Andrew Tanenbaum’s Minix, a UNIX-like operating system not based on an 
existing code, and used as a teaching tool. With the rudiments of memory manage¬ 
ment, and a crude disk device driver, Linux version .01 was released in 1991. 

Linux most closely resembles System V UNIX, and it is more popular today than 
Windows NT. Of course, there are more commercial applications that run under NT, 
but Linux systems don’t have to be rebooted as often. With a cast of thousands working 
on improving Linux (Microsoft employs between 200 and 300 programmers for NT), it 
is a wonder that Linux has not grown to be the size of NT 5 (40 million lines of code). 
Personally, 1 doubt that would ever happen to a UNIX-like operating system. 

Media Driven 

The roots of UNIX go back almost 30 years. Although Linux is a “new” operating sys¬ 
tem, it is also based on UNIX. What about something completely different, starting 
from scratch? Like BeOS. 

BeOS shares little with UNIX - the Bash shell, a POSIX interface, and about 150 UNIX 
commands (including Perl). It also has memory protection (as any real operating sys¬ 
tem should), virtual memory, and preemptive multitasking. Beyond that, it is an entire¬ 
ly new operating system which Be PR describes as the “Media OS.” This is perhaps not 
so far fetched, as the goal of Be is to support digital media - video, audio, 3D models, 
and other graphics. To accomplish this, BeOS is based on a microkernel design, using 
message passing and pervasive multithreading. The multithreading is supposed to aid 
even in single-processor systems by permitting faster preemption. 

Be programmers designed BeOS for multiple-processor systems, using a purely sym¬ 
metric architecture. In asymmetric multiprocessing, one processor acts as “master” and 
runs the operating system, while other processors, the “slaves” can only run application 
code. Symmetric systems permit any processor to run OS code, but there usually is a 
problem. The kernel contains many “critical sections” code that cannot be interrupted 
and certainly not executed simultaneously by a second processor. The usual solution is 
to protect critical sections with locks, mutexes, and semaphores, to guard against multi¬ 
ple access. OS designers have a lot of trouble deciding exactly where to place the locks, 
and most multiprocessor OSs start out with coarse-grained control - locks that guard 
large hunks of code. Be claims to have built an OS avoiding this problem. 

The filesystem supports files 2^^ in size, or single devices as large as 18 million terabytes 
(18 billion gigabytes). While this might seem ridiculous today, you can already buy 
drives that exceed 10 gigabytes, while the maximum file size supported by a 32-bit inte¬ 
ger size is 4 gigabytes. Peeking into the BSDl source, the file offsets are also 64 bits, so 
no problem there. 

BeOS does support other filesystems as well: the Mac OS HFS, DOS Fat 16 and 32, and 
NFS. Currently, all BeOS files appear to be owned by “baron”; there are hooks for 
adding either UNlX/POSlX-style owner and group, or NT ACLs, as each file includes 
extended attributes which can hold anything the programmer desires. 

Networked 

Only TCP/IP is supported, although BeOS can print to AppleTalk printers. As men¬ 
tioned, there is native support for NFS, FTP, and Telnet, and both an integrated Web 
browser and rudimentary server are included. 

The ties of its founder, )ean-Louis Gassee, and the VP of engineering, Steve Sakoman, 
to Apple, where they both worked, are obvious. You probably remember when Apple, 
Inc. considered using BeOS as a replacement for the venerable MacOS, a spaghetti OS 
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with roots in the early 1980s. 1 am not very fond of MacOS, because I have to support 
my wife and son and their PowerPC. An OS that does not protect memory or offer true 
multitasking is really lame. MacOS 10 will be based on Nexts Mach kernel, an 
improvement I pray 1 live to see (there was a nice invited talk about this at the USENIX 
1998 conference in New Orleans). 

Apple did not choose BeOS, but BeOS s native platform is the PowerPC-based Mac. 

Last spring, a version of BeOS for Pentium systems appeared, but it still has limited 
hardware support. I really wanted to load this on a “spare” Intel box, just to see how it 
compared performance-wise to Windows 95, but BeOS for Intel failed to discover the 
CD-ROM, and does not support SCSI CD-ROMs for installation, leaving out my other 
Intel boxes. 

Although BeOS protects memory and devices, it does provide direct access to video 
card memory, something that game and graphic designers want (and need). The devel¬ 
opment platform is C++, with an object-based API. BeOS also includes Silicon 
Graphics’ OpenGL for 3D graphics. Be claims that the objects provided with the system 
encourage pervasive multithreading, and that the message passing means that disparate 
applications can communicate without difficulty. 

Because BeOS is new, its API does not suffer from having to support old, complex, and 
backward-compatible interfaces. 1 must admit this really attracted me; the Win32 API 
and Mac API are enormous, and X, while smaller, is not very simple. Gcc is included, as 
is a basic development environment. The official development tool costs $129. BeOS 
itself costs $100 (although it is on sale for $70 at the time I write this). Check out 
<www.be.com> for more details. 

Enthusiasm 

Be appears to have an exciting new OS, with a small, dedicated group of devotees. 1 
wanted to talk about it because it is an interesting approach, with many, but not all, of 
the features I have been looking for in a new OS. Whafs missing? Built-in security is 
important to me. Broader support for hardware is currently lacking, although 1 imagine 
that will come (hard to image a high-performance filesystem that cannot run on SCSI 
drives on Intel platforms). Still, there is an interesting future here for fledgling hackers 
who want to write graphics software or like having built-in MIDI capabilities. 

BeOS is proprietary - no source code. I am looking for something like BeOS, but more 
open. Still, the price is right, and BeOS appears to be a very good alternative to 
Windows (Rich Text Format conversion is already supported, and one developer has 
plans for full conversion of Word files for their word processor). 

It seems like I install one operating system a month, mostly upgrades or on new hard¬ 
ware. Sometimes this is easy, like installing BSDl or Linux, where you answer some 
questions and walk away, or difficult, like NT, where you must babysit for an hour or 
so. In all cases, dealing with the video adapter and monitor causes the most problems 
(except in notebooks, where the PC cards are problematical). 

Sometimes I wish I could just say, “Make it so,” and some minion would hop to it. But 
then I would miss all the fun. 


Because BeOS is new, its 
API does not suffer from 
having to support old, 
complex, and backward- 
compatible interfaces. I 
must admit this really 
attracted me; the Win32 
API and Mac API are 
enormous, and X, while 
smaller, is not very simple. 
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In our survey of Java performance issues, an important area to consider is I/O. 
Java tends to be somewhat insulated from any underlying operating system, 
and some types of performance issues, for example disk file fragmentation, are 
not addressable by a Java environment. But other kinds of issues are familiar. 

Two of these are method call overhead and buffering. To see how these issues play out, I 
will present a series of examples, all of which solve the same problem of counting the 
number of lines in a text file. 

In UNIX/C the lowest-level way to read a character from a file is to use the read( ) sys¬ 
tem call. The equivalent in Java is the read( ) method of FileinputStream: 

import j ava.io.*; 

public class testl { 

public static void main(String args[]) 

{ 

try { 

FileinputStream fis = 
new FileinputStream(args [0] ); 
int cnt = 0; 
int ch; 

while ((ch = fis.readO) != -1) { 
if (ch == '\n') 
cnt++; 

} 

fis.close(); 

System, out. pr int In (cnt) ; 

} 

catch (lOException e) { 

System.err.println(e); 

} 

} 

} 

A FileinputStream object represents an input stream of bytes from a file. Note that Java 
characters are two bytes long, and so this stream of bytes doesn't necessarily represent 
characters in a one-to-one correspondence. 

The program requires around 10 seconds to execute on a 2MB text file, one with 
around 40,000 lines it, using JDK (Java Development Kit from Sun) 1.1.5. 

But this approach is kind of low-level, and maybe we want to try something more ele¬ 
gant, using Java library classes and methods that already know about text lines. So a 
second approach is to say: 

import j ava.io.*; 

public class test2 { 

public static void main(String args[]) 

{ 

try { 

FileinputStream fis = 
new FileinputStream(args [0] ); 

DataInputStream dis = 
new DataInputStream(fis); 
int cnt = 0; 

while (dis.readLine() != null) 

cnt++; 

dis.close(); 
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System.out .println(cnt) ; 

} 

catch (lOException e) { 

System.err.printIn(e); 

} 

} 

} 

DatainputStream is a class built on top of an input byte stream. It knows about vari¬ 
ous sorts of data types, including text lines. 

It turns out that this approach is actually slightly slower, because readLine () in 
DatainputStream uses the low-level read() illustrated above, with attendant method 
call overhead. DatainputStream. readLine () has been deprecated and should not be 
used in new code. Beyond the performance problems, there are issues with correctly 
converting bytes to characters. 

A newer approach is to use Buf feredReader, a class that solves the method call over¬ 
head, buffering, and conversion problems: 

import j ava.io.*; 

public class test3 { 

public static void main(String args[]) 

{ 

try { 

FileReader fr = new Fi1eReader(args [0] ); 

BufferedReader br = new BufferedReader(fr); 
int cnt = 0; 

while (br.readLine() != null) 
cnt++; 
br.close(); 

System.out.printIn{cnt); 

) 

catch (lOException e) { 

System.err.println(e); 

} 

} 

} 


This program executes in 1.1 seconds, about ten times faster than the previous two 
examples. 

Is there any faster way to solve this problem? If youVe desperate for speed, you can pro¬ 
vide your own buffering, and eliminate the step whereby an accumulated input line is 
converted to a String and returned. This approach looks like: 

inport j ava. io. *; 

public class test4 { 

public static void main (String args[]) 

{ 

try { 

FileinputStream fis = 
new FileInputStream(args[0]); 
int cnt = 0; 
int len; 

byte buf[] = new byte[1024]; 
while (den = fis .read (buf)) > 0) { 
for (int i = 0; i < len; i++) { 
if (buf[i] == '\nd 
cnt++; 
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} 

} 

fis.close(); 

Sys tem. out. print In (cnt) ; 

} 

catch (lOException e) { 

Sys tem. err, print In (e) ; 

} 

} 

} 

This program executes in 0.3 second, or around 35 times faster than the first two exam¬ 
ples. However, manipulating text files in terms of byte streams requires some care, 
because Java uses the Unicode 16-bit character set, and the notion of a “text file” is 
somewhat different from what you might be familiar with. A reasonable compromise is 
to use the technique found in the third example above, a Buf feredReader object lay¬ 
ered on top of a FileReader. FileReader and Buf feredReader know about conver¬ 
sion between bytes and characters. 

Similar sorts of performance considerations apply to output. For example, a statement 
like: 

System, out .printIn {“ testing") ; 

uses line buffering in support of interactivity, but if you're wiUing to disable line buffer¬ 
ing, you can improve the output performance considerably. 
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Introduction 

The POSlX.ld draft standard is the third 
in a series of realtime POSIX operating 
system interface standards. The first stan¬ 
dard, POSIX.lb-1993, specifies interfaces 
in nine areas: realtime signals, synchro¬ 
nized I/O, asynchronous I/O, sema¬ 
phores, memory locking, memory 
mapped files and shared memory, priori¬ 
ty scheduling, high resolution clocks and 
timers, and message passing. The second 
standard, POSIX. Ic-1995, specifies a 
number of interfaces that together define 
a threads extension to the POSIX. 1-1990 
process model. The standards body 
responsible for the development and 
maintenance of all the POSIX standards 
is the IEEE Portable Applications 
Standards Committee (PASC). The par¬ 
ticular PASC working group that focuses 
on the realtime POSIX standards is 
known as the Systems Services Realtime 
Working Group and is the successor to 
the fabled POS1X.4 Working Group. 

POSlX.ld specifies additional interfaces 
in support of the realtime goals of pre¬ 
dictability and high performance. The 
interfaces fall into seven areas: 

■ Process creation via posix_spawn {) 



■ Sporadic server execution scheduling 
policy 

■ Execution time monitoring of 
processes and threads 

■ I/O advisory information 

■ Timeouts for selected blocking 
functions 

■ Device control 

■ Interrupt control 

In the POSlX.ld draft standard, these 
interfaces are specified as a number of 
options to POSIX. 1, as amended by 
POSlX.lb and POSlX.lc. Most of the 
options can be implemented indepen¬ 
dently of other options. This means that 
operating system vendors can choose to 
implement some POSlX.ld interfaces 
and not others, just as they can choose to 
implement some POSlX.lb and 
POSlX.lc interfaces and not others. 
Likewise, users must decide which 
optional interfaces they require, and pur¬ 
chase operating systems that implement 
those required interfaces. It should be 
noted that some options are dependent 
on the existence of certain other options. 
The options and their dependencies are 
described in the following sections. 

As the POSlX.ld draft standard matures, 
the Working Group will fold subsets of 
the options specified in the draft stan¬ 
dard into existing and/or new application 
environment profiles. The existing pro¬ 
files are documented in POSIX. 13-1998. 

Process Creation Via posix_spawn () 

The POSlX.ld draft standard introduces 
interfaces for enabling an application to 
create a new process - including loading 
a new process image containing new exe¬ 
cutable code into the new process’s 
address space-in a single step. These 
interfaces can be used in place of the 
POSIX. 1 process creation interfaces, 
which entails two steps: first a fork() to 
create a process whose process image is a 
copy of the parent s process image, and 
then an exec () to overlay the copy of the 
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parent s process-image with a new image, taken from a specified 
executable file. This two-step process creation mechanism can 
waste resources; one process image is loaded, and then it is 
immediately replaced by another process image. More signifi¬ 
cantly, the two-step mechanism places an undue hardship on 
systems lacking memory management units (MMUs) or other 
hardware support for dynamic address translation, because such 
systems cannot readily implement the fork() operation. The 
problem is that, without dynamic address translation, the 
addresses in a process image are actual physical addresses. 
Therefore, the child's process image, if it were indeed an exact 
copy of the parent s process image, would be competing for the 
same physical memory as the parent’s process image. 

The new process creation interfaces, which are available under 
the Spawn option, are posix_spawn () and posix_spawnp (). 

Both of these create a new process, whose process image is con¬ 
structed from a specified executable file referred to as the new 
process image file. The posix_spawn {) operation takes a fully 
defined pathname as an argument; the posix_spawnp { ) opera¬ 
tion builds a pathname from a file argument and the PATH 
environment variable of the calling process. Both operations 
enable the creator to specify arguments and environment strings 
for the newly created process. In addition, both operations 
enable the creator to specify^ how file descriptors, process group 
IDs, signal masks, and default signal actions are handled at 
process creation. 

POSIX.5 defines the start_Process Ada language procedure 
that performs a function nearly identical to that of 
posix_spawn (). While preparing Draft 11 of POSIX.ld, the 
Working Group considered making posix_spawn () a C lan¬ 
guage binding to Start_Process, but realized that doing so 
would be detrimental to the realtime goals that motivated the 
development of posix_spawn () in the first place. Therefore, the 
Working Group decided to keep posix_spawn () simple and effi¬ 
cient, forgoing some of the power of Start_Process. The 
Start_Process procedure allows the caller to specify an arbi¬ 
trarily long ordered script of file open, close, and duplicate oper¬ 
ations to be performed for the new process before the new 
process image begins execution; the posix_spawn () function 
allows the caller to specify only how each file descriptor in the 
new process either is mapped to an open file descriptor in the 
calling process or remains closed. Other than this, 
posix_spawn( ) provides the same functionality as 
Start_Process and, in fact, Start_Process may be directly 
implemented using posix_spawn ( ) in the case where the caller- 
specified script of file actions is empty. 

Sporadic Server Execution Scheduling Policy 

The POSIX.ld draft standard supplements the existing POSIX 
priority scheduling facilities with the sporadic server scheduling 


policy, a mechanism for scheduling aperiodic tasks in a primari¬ 
ly periodic environment [Sprunt et al. 89). The sporadic server 
scheduling policy was developed as an extension to the rate 
monotonic scheduling policy. It is based on dynamic changes to 
the priority of a “sporadic server” set up by an application to 
service a stream of aperiodic task arrivals; the changes in the pri¬ 
orities are made by the operating system in accordance with 
parameters supplied by the application and a set of rules spelled 
out in POSIX.ld. In particular, the priority of the sporadic serv¬ 
er is varied between two application-specified levels: a (normal) 
high foreground priority and a low background priority. The 
aim of the priority assignment rules is to allow the aperiodic 
tasks serviced by the sporadic server to execute at a high priority 
as long as their execution does not pose a threat to the hard 
deadlines of other tasks. 

In short, the sporadic server scheduling policy allows aperiodic 
tasks to be served at a high priority for a bounded amount of 
time and at a low background priority at other times. The high- 
priority service provides the aperiodic tasks with a better average 
response time than they might otherwise receive. At the same 
time, the low-priority service that kicks in when they meet their 
bound on high-priority service prevents them from interfering 
with hard-deadline periodic tasks, because the aperiodic tasks 
are then forced to execute in the background and so cannot 
flood the processor. 

The sporadic server scheduling policy is characterized by four 
parameters, in addition to the normal priority used in POSIX. lb 
and POSIX. Ic: 

1. Low priority: the priority level at which the sporadic server 
executes (i.e., services aperiodic task arrivals) while in the 
background. While in the foreground, the sporadic server exe¬ 
cutes at the normal (high) priority. 

2. Replenishment period: the length of the time intervals over 
which the foreground CPU-time usage of the sporadic server 
is monitored and limited. 

3. Initial budget: a bound on the amount of CPU-time that the 
sporadic server can consume while executing in the fore¬ 
ground during any time interval of length equal to the replen¬ 
ishment period. 

4. Maximum number of pending replenishment operations: this 
value effectively limits the number of aperiodic tasks that can 
be serviced during any time interval of length equal to the 
replenishment period. The point of having this limit is to 
bound the amount of system overhead (storage and CPU 
time) required to implement the sporadic server scheduling 
policy. 

Under the Process Sporadic Server and Thread Sporadic Server 
options, the POSIX.ld draft standard adds these four parameters 
to the process scheduling parameter structure of POSIX.lb and 
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to the thread scheduling parameter attribute of POSIX.lc. It also 
amends the following POSIX.lb and POSIX.lc execution sched¬ 
uling functions to take these parameters into account: 

■ The POSIX.lb functions for assignment of the scheduling 
parameters (sched_setparain()) and the scheduling policy 
plus parameters (sched_setscheduler ()). 

■ The POSIX.lb functions sched_getparain() and 
sched_getscheduler () are implicitly amended. Because of 
the way the sched_getparam() and sched_getscheduler () 
functions are worded in POSIX.lb, it is not necessary to 
explicitly modify the functions. That is, the descriptions of the 
functions do not call out other scheduling policies and para¬ 
meters by name, so it is not necessary to amend the functions 
to call out the new sporadic server policy and parameters by 
name. The wording was intentionally designed to make these 
interfaces extensible in this regard. 

■ The POSIX.lc functions for assignment and retrieval of 
scheduling attributes in thread attributes objects for use in 
thread creation: pthread_attr_setschedpolicy (), 
pthread_attr_getschedpolicy (), pthread_attr_- 
setschedparam (), pthread_attr_getschedparain (). 

■ The POSIX.lc functions for dynamic assignment and retrieval 
of thread scheduling policy plus parameters: 
pthread_setschedparam() and 

pthread_getschedparam{). Note that it is implementation- 
defined whether an application can dynamically change its 
scheduling policy to the sporadic server scheduling policy. 

Execution Time Monitoring of Processes and Threads 

The POSIX.ld draft standard supplements the clock and timer 
facilities of POSIX.lb through two options: the Process CPU- 
Time Clocks option and the Thread CPU-Time Clocks option. 

In particular, it defines two new types of clocks: 

■ Process CPU-time clocks 

■ Thread CPU-time clocks 

In a POSIX.lb clock or timer function call, the CPU-time clock 
of the calling process is designated by the symbol 
CL0CK_PR0CESS_CPUTIME_ID, and the CPU-time clock of the 
calling thread is designated by the symbol 
CLOCK_THREAD_CPUTIME_ID. 

These clocks can be used to monitor the CPU usage of processes 
and threads, as well as to establish limits on such usage through 
the setting of timers. As stated in IEEE POSIX.ld, the mecha¬ 
nism used to measure CPU time is implementation-defined; 
thus, the resolution and accuracy of the CPU-time clocks is 
implementation-dependent. The software data structure used for 
representing time, however, is standardized by POSIX.lb, for the 
sake of application portability. Specifically, the POSIX.lb data 
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Structure provides for nanosecond resolution, although practical 
computer clocks are not nearly that good. 

The functionality provided by CPU-time clocks can be used dur¬ 
ing the development and operation of many realtime applica¬ 
tions, as in the following examples: 

■ During development, the CPU-time monitoring capability 
facilitates the collection of information that is vital to system 
engineers in analyzing the ability of a realtime application to 
meet its performance specifications. 

■ During operation, the capability of setting CPU-time limits 
can be used to enhance the robustness of an application, by 
enabling the application to prevent a potentially faulty process 
from capturing the CPU. 

■ During operation, the capability of setting CPU-time limits 
can be used to facilitate the scheduling of certain realtime 
applications, such as those having iterative components whose 
results become more precise with each iteration. For example, 
an iterative component might be allowed to execute at a high 
priority until it reaches its CPU-time limit, at which point it is 
considered to have achieved an “acceptable” but imprecise 
result (i.e., a result - with bounded imprecision - that has 
been shown through a priori analysis to be acceptable, 
although not optimal, to the application). Then the iterative 
component might be allowed to execute at a low priority, 
improving the precision of its result, up until its deadline. At 
its deadline, the iterative component provides its (possibly still 
imprecise) result to the application. The idea behind returning 
an imprecise result at the deadline is that a timely result of 
bounded imprecision is better than a precise, but late, result 
(see [Chung et al. 90] for an overview of how to schedule 
“imprecise computations”). 

The measurement of thread execution time may incur excessive 
overhead in some systems and some applications. Therefore, a 
new thread creation attribute is introduced by the POSIX.ld 
execution-time monitoring facility. This attribute allows/disal¬ 
lows thread access to CPU-time clocks; it is set at thread cre¬ 
ation-time and is unchangeable thereafter, making it possible for 
an operating system to optimize the implementation of a given 
thread. 

The specific functions introduced by the POSIX.ld draft stan¬ 
dard include the following: 

■ Getting the clock ID of the CPU-time clock of a specified 
process (clock_getcpuclockid()). 

■ Getting the clock ID of the CPU-time clock of a specified 
thread (pthread^etcpuclockid ()). 

■ Setting or getting the value of the CPU-time clock thread cre¬ 
ation attribute (pthread_attr_setcpuclkallow(), 
pthread__attr_getcpuclkallow()). 
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I/O Advisory Information 

The capability of performing I/O operations with deterministic 
high performance is crucial in realtime systems. To this end, the 
POSIX.ld draft standard proposes interfaces for enabling an 
application to give the operating system advisory information on 
how the application expects to use specified file and memory 
space. Notably, the application does not tell the operating system 
how to manage file and memory access; it just offers “hints” 
relating to characteristics of the application, which the operating 
system can take into account in making its resource manage¬ 
ment decisions. The specific interfaces, available under the 
Advisory Information option, are as follows: 

■ Providing advisory information on how the application 
expects to use a specified range of a specified file (posix_fad- 
vise ()). The information is conveyed through an advice 
argument that has a number of standard values. 

■ {P0SIX_FADV_N0RMAL} No further special treatment 

■ {POSix_FADV_SEQUENTiAL} Expect sequential references 

■ {P0SIX_FADV_RAND0M} Expect random references 

■ {P0SIX_FADV_WILLNEED} Will need the specified range soon 

■ {P0SIX_FADV_IX)1SITNEED} Don’t need the specified range 
anymore 

■ {POSIX_FADVJSIOREUSE} Expect data will not be reused once 
accessed 

■ Providing advisory information on how the application 
expects to use a specified range of memory (posix_mad- 
vise ()). This function is available if the Memory Mapped 
Files option or the Shared Memory Objects option, in addi¬ 
tion to the Advisory Information option, is supported. Like 
the posix_fadvise( ) function, this function conveys infor¬ 
mation through an advice argument having a number of stan¬ 
dard values. The values are labeled {posix_madv_NORMAL} , 

{POSIX_MADV_SEQUENTIAL}, { POSIX__MADV_-RANDOM}, 
{POSIXJJW)VJWILLNEED}, {POSIX_MADV_DONTNEED} , and 
have the same meanings as the values used with 
posix_fadvise(). 

Note that there is no posix_inadvise () advice argument 
value corresponding to the posix_fadvise () advice argu¬ 
ment value {FADV_NOREUSE} . This is because “reuse” of data is 
accomplished through explicit application-specified sharing of 
memory in the case of memory mapped files and shared 
memory objects, whereas reuse is accomplished through oper¬ 
ating system buffering in the case of nonmapped files. 

Also in the interest of enabling an operating system implementa¬ 
tion and an application to work together to optimize perfor¬ 
mance, the POSIX.ld draft standard introduces the following 


new pathname variables which provide the indicated informa¬ 
tion on files: 

Name: {ALLOC_siZEjyiiN} 

Description: Minimum number of bytes of storage actually allo¬ 
cated for any portion of a file. For direct (unbuffered) I/O, the 
number of bytes transferred in an I/O operation should be a 
multiple of {ALLCX:_SIZE_MIN} . The file offset should also be a 
multiple of {ALL0C_SIZE_MIN) . Valid increments for file trans¬ 
fer sizes between the {posix_rec_min_xfer_size} and 

{POSIX_REC_INCR_XFER_SIZE}{POSIX_REC_-MAX_XFER_SIZE} 

values. Note that {posix_REC_incr_xfer_size} should be a 
multiple of {allcx:_size_min}. 

Name: {posix_rec_min_xfer_size} 

Description: Minimum recommended file transfer size. 

Name: {posix_rec_max_xfer_size} 

Description: Maximum recommended file transfer size. 

Name: {posix_rec_xfer_align} 

Description: Recommended file transfer buffer alignment. 

An application can use the POSIX. 1 functions pathconf () and 
fpathconf {) to determine the current value of each of these 
variables for any given pathname. The application can then use 
the values to optimally set up its transfers of data between files 
and memory. 

The POSIX.ld draft standard proposes the following additional 
interfaces, available under the Advisory Information option, that 
further assist applications in optimizing their performance: 

■ Pre-allocating or releasing a specified amount of storage space 
for a specified file (posix_fallocate {), posix_f free ()). 
The file size is not affected by these functions. Thus, space can 
be pre-allocated beyond the current end of the file. This 
enables append-mode writes to take advantage of the pre-allo¬ 
cation offered by posix_fallocate (). 

■ Allocating a block of memory of a specified size on a specified 
alignment (posix__memalign ()). The block can be freed with 
the C Standard free () function [ISO/IEC C]. 

rtmeouts for Selected Blocking Functions 

Prior to the development of the POSIX.ld draft standard, some 
POSIX.lb and POSIX. Ic blocking functions had timed versions 
(i.e., versions that would block subject to a specified timeout 
period), while others did not. The timed versions included the 
following: 

■ The POSIX.lb function sigtimedwait (), a timed alternative 
to sigwaitinfo (). 

■ The POSIX. Ic function pthread_cond_timedwait (), a timed 
alternative to pthread_cond_wait (). 
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■ The POSIX.lb function aio_suspend () with a non-NULL 
timeout argument, a timed alternative to aio_suspend() with 
a NULL timeout argument. 

The Working Group came to view the lack of timed versions of 
blocking functions as a serious shortcoming, especially in the 
context of life-critical or mission-critical embedded systems. In 
these systems, an application must ensure that unbounded 
blocking can never result from a service request, since unbound¬ 
ed blocking causes the application to lose control of the system. 
An application s loss of control is intolerable in realtime systems, 
for it is the application that is supposed to be directing the sys¬ 
tem in support of the mission. Therefore, an application must be 
able to detect and to escape from what it considers to be an 
unreasonable delay in receiving service, and hence to regain con¬ 
trol of the system. Upon regaining control, the application may 
invoke some system-specific fault diagnosis and fault recovery 
procedures. 

Therefore, all the blocking functions of IEEE Stds POSIX.I, 
POSIX.lb, and POSIX.lc were reviewed. It was decided to be 
unnecessary to supplement blocking I/O services with timed ser¬ 
vices, because asynchronous (nonblocking) services had already 
been added to the standard under the IEEE Std POSIX.lb 
Asynchronous I/O option. In the end, only the following timed 
functions were added to POSIX.I (as amended by IEEE Stds 
POSIX.lb and POSIX.lc), under the Timeouts option: 

■ The function sem_timedwait (), as a timed alternative to the 
POSIX.lb function sem_wait() (POSIX.Id, Section 11.2.6). 

■ The function pthread_nvutex_timedlock{ ), as a timed alter¬ 
native to the POSIX.lc function pthread_mutex_lock () 
(POSIX.Id, Section 11.3.3). The pthread_ntutex_tiined- 
lock () function can be used only with mutexes whose time¬ 
out-allowed attribute is set to pthread__timeout_allowed. 
The timeout-allowed attribute was introduced under the 
Timeouts option as a performance-preserving mechanism. An 
application programmer can set the timeout-allowed attribut¬ 
es of selected mutexes to pthread_timeout_disallowed to 
avoid the overhead associated with the mutexes being set up to 
handle timed locks. 

■ The functions mq_timedsend () and mq_timedreceive (), as 
timed alternatives to the POSIX.lb functions mqL.send{ ) and 
inq_receive () (POSIX.Id, Sections 15.2.4-15.2.5). 

Device Control 

The POSIX.Id draft standard addresses device control in Annex 
I. This annex, which is informative only (i.e., not a normative 
part of the draft standard), suggests standardizing the function¬ 
ality of the traditional UNIX function ioctl () in the form of a 
new function called posix_devctl {), which would be available 
under a Device Control option. In earlier drafts of POSIX. Id, 


the posix_devctl () function was specified in normative text in 
the main body of the document. However, some members of the 
balloting group opposed the inclusion of a device control func¬ 
tion in the draft standard, even as an optional interface, and so, 
in the interest of consensus building, the technical reviewers 
decided to move the specification of posix_devctl () into an 
informative annex. This section describes the suggested 
posix_devctl () function, the motivation behind it, and some 
of the objections to it. 

The UNIX function ioctl (), although proven in practice to 
provide essential functionality, was recognized as having some 
room for improvement in its specification. Thus, in designing 
the posix_devctl () function, the Working Group was driven 
by two somewhat conflicting goals: (1) maintaining compatibili¬ 
ty with current ioctl () implementations, and (2) establishing 
sound definitions of the posix_devctl () arguments and return 
value. 

The motivation behind the posix_devctl {) function lies in the 
fact that the I/O capabilities of POSIX.I fall short of meeting the 
I/O needs of realtime applications, as well as other applications. 
The problem is that many applications need to interact with I/O 
devices not contemplated by POSIX. 1. The applications can 
choose to interact with such devices in one of two ways: (1) 
through device drivers or (2) through application code, directly 
using the POSIX. Id interrupt control facility. In Draft 11 of the 
POSIX.Id draft standard. Annex I, “Device Control Considera¬ 
tions,” addresses the first approach; Annex J, “Interrupt Control 
Considerations,” addresses the second approach. 

POSIX. 1 specifies general-purpose I/O functions, including 
open {), close (), read (), write (), and Iseek () . These I/O 
functions are designed to capture the functionality of random- 
access mass-storage devices such as disks. Devices whose func¬ 
tionality is not completely captured by the general-purpose I/O 
functions are considered to be “special devices.” POSIX.I 
addresses only one type of “special device,” terminal I/O. It 
defines device-specific functions for terminals that enable an 
application to specify the number of bits per character, the type 
of parity, the baud rate, etc., for an asynchronous serial commu¬ 
nication port. 

Realtime systems typically encompass special devices other than 
terminals. Some of the special devices are common commercial¬ 
ly available devices, while others are unique application-specific 
devices. For common commercially available devices (e.g., mag¬ 
netic tape drives and printers), it would be theoretically possible, 
although not necessarily practical, to define a full set of device¬ 
specific I/O functions such as those defined for terminals. 
However, for unique application-specific devices (e.g., specific 
actuators, sensors, or other controlled devices), it would be 
impossible to define a full set of device-specific I/O functions, 
because new devices are continually being developed for new 
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applications. The functions needed by these yet-to-be-invented 
devices cannot be anticipated and thus cannot be defined or 
standardized. 

The posix_devctl {) function that is suggested in Annex I of 
the POSIX.ld draft standard does not attempt to standardize 
individual device-specific functions. Instead, it serves as a “stan¬ 
dard” mechanism for transmitting any “nonstandard” (i.e., 
device-specific) I/O commands to any special devices. The 
posix_devctl () function is, in practice, a general application 
program interface to the device drivers for “special devices.” That 
is, in the posix_devctl () model of communication between 
application software and device drivers, application programs 
funnel all device-specific I/O commands through the 
posix_devctl () interface. 

The posix_devctl {) function provides a layer of standardiza¬ 
tion that has proven to be useful, as evidenced in the widespread 
use of the ioctl () function. The posix_devctl () function 
benefits two groups: 

1. Users of device drivers for special devices. Users are given a 
uniform model of communication between application soft¬ 
ware and device drivers. The model isolates device-specific 
application code into readily recognizable locations (i.e., at 
posix_devctl () function calls). Thus, application portability 
is improved. For example, application software that interacts 
with a specific analog-to-digital converter can be “ported” rel¬ 
atively easily to interact with another analog-to-digital con¬ 
verter, if the device drivers for both analog-to-digital convert¬ 
ers implement the posix_devctl () function. 

2. Writers of device drivers for special devices. (As previously 
noted, these writers may be application developers, as in the 
case of unique application-specific devices.) The model that 
the posix_devctl () function imposes on communication 
between application software and device drivers serves as a 
guide to device driver writers. In this way, the 
posix_devctl () function tends to simplify the development 
of device drivers. In the same way, the posix_devctl () func¬ 
tion tends to simplify the porting of device drivers when 
devices need to be moved to different systems. 

Like the common ioctl () function, the posix_devctl () func¬ 
tion has the following arguments: (1) a file descriptor of an open 
device, (2) a driver-specific command requesting the designated 
device to perform some action, and (3) a pointer to a buffer 
whose content is command-dependent and therefore also driver- 
specific. Data is passed between the device driver and the buffer 
in a command-dependent direction. 

The posix_devctl () function has two additional arguments: 

(1) a byte count of the data to be passed between the device dri¬ 
ver and the buffer and (2) a pointer to a word (specifically, a 
data object of type int) of driver-specific device information that 


may be returned by the function in addition to the usual suc¬ 
cess/failure indication. In the interest of compatibility with the 
ioctl () function, a byte count of zero can be used to indicate 
that the amount of data to be passed between the device driver 
and the buffer is unspecified. Also in the interest of compatibili¬ 
ty, the device information word can be used to report informa¬ 
tion that, in the case of the ioctl {) function, would be reported 
via the function return value. 

The fact that the posix_devctl () function has driver-specific 
arguments (i.e., the command, the buffer, and the device infor¬ 
mation word) is the source of the most serious objections to the 
function. Some balloters do not see the value of the level of stan¬ 
dardization provided by the posix_devctl () function. In their 
minds, a function which is by its very nature so implementation- 
specific (and, moreover, driver-specific) simply is not a candi¬ 
date for standardization in POSIX.ld or in any other amend¬ 
ment to POSIX.l. On the other side of the controversy, the pro¬ 
ponents of the posix_devctl () function point to the ubiquity 
of the UNIX function ioctl () as proof of the usefulness of 
standardizing device control at the “template” level, where the 
template is standard and the elements of the template are driver- 
specific. 

Interrupt Control 

Annex J of the POSIX.ld draft standard proposes an optional 
interrupt control facility that would make interrupts visible to 
the application. This facility represents a departure from tradi¬ 
tional UNIX practice but is in keeping with realtime kernel prac¬ 
tice. 

The interrupt control facility, like the device control facility, was 
at one time specified in normative text in the main body of 
POSIX.ld, but was moved to an informative annex in response 
to opposition from some balloters. The opposition stemmed 
from the same fundamental issue facing device control: interrupt 
control is inherently implementation-specific. The remainder of 
this section describes the proposed interrupt control facility and 
explains how it could be used to improve application portability. 

The interrupt control facility put forward in Annex J offers two 
primary capabilities: (1) An application can associate user-writ¬ 
ten interrupt service routines (ISRs) with specified interrupts. 

(2) An application can request to be notified of the occurrence 
of a specified interrupt. These interfaces are aimed at enabling 
“connection of nonstandard interrupt-generating hardware in a 
standard way” [POSIX.ld, Section J.5.1.1]. Here, “nonstandard 
hardware” means special devices not supported by the operating 
system vendor. As noted in Section 8, “Device Control,” special 
devices are common in realtime systems. Application developers 
could use the POSIX.ld interrupt control facilities to manage 
special devices in user-level application code. The alternative 
would be to manage special devices in full-fledged device dri- 
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vers, installed in the operating system and executed in kernel 
mode. 

The motivation behind the interrupt control facility is given in 
the POSIX.ld draft standard [POSIX.ld, Section J.5.2]: 

Although interrupt handling isn't entirely portable, there is 
still profit in standardizing the interrupt control interface. 

First is the implicit standardization of core functionality. 
Second is programmer portability. Third is that interrupt han¬ 
dling code can follow the hardware device for which it was 
written.... The resulting modularization and isolation of 
nonportable code also aids portability. 

The specific interfaces that would be available under the 
Interrupt Control option are as follows: 

■ Associating a specified user-written ISR, with a specified inter¬ 
rupt, or disassociating the ISR and the interrupt 
(posix_intr_associate (), posix_intr_disassociate {)). 
The process of associating a user-written ISR with an inter¬ 
rupt is referred to as “registering” the ISR with the operating 
system. 

The target interrupt is specified through an argument of type 
intr__t, whose value identifies an interrupt in an implementa¬ 
tion-defined manner. 

When registering the ISR, the application specifies the address 
and size of a “communication region,” an area of memory 
through which the ISR and the application can exchange data. 
The communication region is simply an area in the address 
space of the registering process that the application chooses to 
make accessible to the ISR. Upon invocation of the ISR, the 
operating system passes the address of the communication 
region to the ISR as its first argument. In this way, the ISR can 
gain access to a region of the registering process’s address 
space, even if the ISR executes in a context different from that 
of the registering process. 

In Annex J of POSIX.ld, the execution context of ISRs is 
declared to be implementation-defined. In many cases, the ISR 
will execute as a thread in the context of the operating system 
or kernel; in other words, it will execute as a kernel thread. In 
such cases, the address spaces of the registering thread and the 
ISR are different. This is why a pointer to a “communication 
region” must be explicitly passed to the ISR upon invocation. 

■ Specifying to the operating system whether or not the thread 
that registered a given ISR should be notified when an inter¬ 
rupt is handled by the ISR. This is accomplished through the 
ISR return value, which is used as a code for indicating (1) 
whether or not the interrupt washandled and (2) if it was, 
whether or not the registering thread should also be notified. 

The model envisioned in Annex J of the POSIX.ld draft stan¬ 
dard is as follows. Multiple devices are typically mapped onto 
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the same interrupt. For each device, the user may write a sepa¬ 
rate ISR. Then the multiple ISRs are registered for the inter¬ 
rupt. The registered ISRs are invoked in last-registered- first- 
invoked order upon an occurrence of the interrupt. When 
invoked, an ISR must poll its device to determine whether or 
not its device was the source of the interrupt. If its device was 
not the source, then the ISR sets its return code to indicate 
“not handled” and returns immediately. If its device was the 
source of the interrupt, then it handles the interrupt and sets 
the return code to indicate “handled” and “notify” or “do not 
notify,” and it returns. 

■ Designating a specified segment of application code as a criti¬ 
cal section whose execution must not overlap the execution of 
a specified ISR (or ISRs). Typically, the protected application 
code and the protected ISR(s) require mutually exclusive 
access to shared data, in particular, the communication region 
(or some part thereof) that is identified at the time of ISR reg¬ 
istration. 

The “protected application code” is the code that falls between 
posix_intr_lock () and posix_intr_unlock () function 
calls. In other words, a thread signifies its intention to enter a 
critical section by calling the posix_intr_lock () function. 

In the posix_intr_lock{) function call, the thread specifies 
an interrupt as the single argument. The “protected ISRs” are 
the user-written ISRs registered by the calling thread for the 
specified interrupt. 

The protected ISRs cannot begin executing while the protected 
application code is executing; likewise, the protected applica¬ 
tion code cannot begin executing until any protected ISR 
active at the time of the posix_intr_lock {) call has com¬ 
pleted. The mechanisms used to ensure mutual exclusion 
between protected application code and protected ISRs are 
implementation defined. Possible mechanisms include operat¬ 
ing system (i.e., kernel) mutexes and hardware disabling of 
interrupts. In addition, several details of these interfaces, such 
as whether or not locking a given interrupt for a given thread 
causes other interrupts (e.g., the same interrupt for other 
threads, or lower-priority interrupts for the same thread or 
other threads) to also be locked, are also implementation 
defined. 

■ Waiting for notification of an (unspecified) interrupt 
(posix_intr_timedwait ()). The duration of the wait can be 
bounded through specification of a timeout argument. 

Status of the POSIX. Id Draft Standard 

The POSIX.ld draft standard was first balloted at Draft 8 in 
December 1993. It was recirculated at Draft 10 in March 1997. 
Due in part to the time that lapsed between the first ballot and 
the recirculation, many balloters failed to respond to the recircu¬ 
lation. Faced with a nonresponsive ballot group, the Working 
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Group decided the only way to make progress was to re-form the 
ballot group. This step was completed in July 1998. 

The POSIX.ld draft standard is being reballoted, with the new 
ballot group, at this time. The results should be available in 
October 1998. Then ballot resolution will begin. Since the ballot 
resolution process may lead to changes in the draft standard, the 
reader should regard this paper as a snapshot of the draft stan¬ 
dard as it stands at Draft 11. 
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Note 

Due to space limitations, an article on the single European cur¬ 
rency by Finnbar P. Murphy will be published in the next regular 
issue o{ ;login: in February, 1999. In the meantime, interested 
readers may find that article at 

<http://www.usenix.org/publications/login/standards/standards.html>. 
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by Peter H. Salus 

Peter H. Salus is a member 
of ACM, the Early English 
Text Society, the Trollope 
Society, and is a life member 
of the American Oriental 
Society. He has held no 
regular job in the past 
lustrum. He owns neither a 
dog nor a cat. 

<peter@pedant.com> / 

I was in San Diego in September for the 
Tcl/Tk conference, and someone asked 
me how I could read so many books. I 
suppressed the urge to tell him that 1 
didn’t read the books at all and instead 
pointed out that a few weeks earlier 1 had 
flown Boston to San Jose and back and 
now Boston-San Diego. In October, it’s 
Boston-LA, and in November, Boston- 
Amsterdam. At roughly six hours of 
reading per flight, that’s a lot of books 
consumed inside aluminum cylinders. 

One of the (funny) problems that arises 
is what to do with the “losers.” 1 left one 
in a plane in August, only to have a flight 
attendant run after me with it. You can 
toss magazines and newspapers, but not 
hard-bound computer books, 1 guess. 

My “top ten” list is at the end of this col¬ 
umn; this year it contains several notes 
concerning items not on the list. 

Stringing Along 

John Vacca’s Cabling Handbook is an out¬ 
standing piece of work. This is a really 
comprehensive guide to telecomms and 
LAN cabling, from Category 5 twisted 
pair to fiber. Standards, planning, cost- 
justification, and installation/implemen¬ 
tation are all handled in an exemplary 
fashion. Only one quibble: Vacca does 
not discuss jacks. The RJ-11 [phone 
plug], RJ-14 [2-phone modular plug], 
RJ-22 [handset plug], RJ-45 [8-pin data 
transmission], RJ-48X [smart jack], etc., 
are not here. You can’t connect those 
cables without jacks. 


AIX 

1 admit that the last time 1 used AIX was 
nearly a decade ago. But Miller has pro¬ 
duced a small volume that reads well and 
appears to combine a tutorial with refer¬ 
ence material for those working on 
RS/bOOOs. Miller’s discussions of migra¬ 
tion problems are quite illuminating. 

C++ 

Vandevoorde has produced the perfect 
adjunct to Stroustrup’s third edition of 
The C++ Programming Language: a full 
explanation and discussion of 
Stroustrup’s exercises, with appropriate 
cross-references to Stroustrup. Fine work. 

Perl 

Perl books seem to multiply nearly as fast 
as Java books did last year. The Perl 
Cookbook tricked me, because it has a 
bighorn sheep on its cover: after cameli- 
dae on the other covers, 1 didn’t expect 
this. The organization of the Cookbook is 
quite fascinating. It is divided into chap¬ 
ters (“Strings,” “Arrays,” “File Contents,” 
“Directories,” etc.) and each of these con¬ 
tains entries of the form: Problem, 
Solution, Discussion, and See Also. Really 
sharp. I found a lot of information that 1 
hadn’t been aware of; the organization is 
solid; the explanations are very fine. 
Christiansen and Torkington have per¬ 
formed a great service. Now, about that 
sheep ... 

Reappearances 

The camelidae are still on the cover of 
the Perl 5 Pocket Reference. This second 
edition is revised for Perl 5.005 and is 
still the perfect carry-around or desktop 
item. Vromans has kept up the excellent 
job he began two years ago. 

The second edition of HTML brought us 
up to HTML 3.2; the new third edition 
takes us to HTML 4.0. Musciano and 
Kennedy’s work has also gained over 50 
pages in the past year. Their exposition 
and explanations are excellent. There is a 
tearout reference card that’s really useful 
(1 replaced my grimy and tattered one 
from 3.2 two weeks ago). 



Books reviewed in this column: 


"John VScca- 


The Cabling Handbook 

Upper Saddle River, NJ: Prentice Hall, 1999. 
ISBN 0-13-080531-9. Pp. 684. 


Bonnie Miller _ 

AiXlif ui^ p 

Upper Saddle River, NJ: Prentice Hall, 1999. 
ISBN 0-13-757246-8. Pp. 184. 

David Vandevoorde _ 

C^+ Solutions 

Reading, MA: Addison Wesley Longman, 1998. 
ISBN 0-201-30965-3. Pp. 292. 

Tom Christiansen & Nathan Torkington 


7 

A 


Sebastopol, CA: O’Reilly 8( Associates, 1998. 

ISBN 1-56592-243-3. Pp. 757. 

Johan Vromans 

. 

Sebastopol, CA: O’Reilly 8i Associates, 1998. 

ISBN 1-56592-495-9. Pp. 67. 

Chuck Musciano & Bill Kennedy _ 

HTML ThejptefMtiv^pJi^ 3rd 

Sebastopol, CA: O’Reilly 8c Associates, 1998. 

ISBN 1-56592-492-4. Pp. 587. 

W. Richard Stevens _ 

voL 2,2nd ed. 

Upper Saddle River, NJ: Prentice Hall, 1999. 
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If you use Perl 5, Vromans is a must; if 
you use HTML, go to Musciano and 
Kennedy. 

Vm not sure what to write about Rich 
Stevens’s revision of UNIX Network 
Programming. It s really excellent, but I’m 
certain to say this about his next work, 
too. Like so many things, it has waxed 
since its first appearance in 1990. Then it 
was in one volume of under 800 pages. 
Volume 2 alone is now 560 pages. And it 
is concerned with the single topic of 
interprocess communication. As nearly 
all programs involve IPCs, this is by no 
means inappropriate. 

Moreover, Stevens really covers the map 
in terms of different UNIXes. A great 
example of this is on pp. 460-461, where 
there are graphs for bandwidth of vari¬ 
ous types of message passing for Solaris 
and for Digital UNIX on facing pages. 

I wonder what Stevens will turn to next. 
Perhaps a revision of the TCP/IP vol¬ 
umes for IPv6? 

Each year the publishers make it harder 
for me to put together a list of “best 
books.” They do this by publishing more 
and more: but they don’t expand my 
reading speed, nor the constraints of the 
clock and calendar. In 1995 I received 
720 books for review; the next year it just 
topped 1000; last year it was nearly 1300. 
I’m certain that 1998 will have brought 
yet more. I read about 100 of these a 
year. I actually write something about 
two-thirds of them. The ones below are 
good books on a variety of topics (one 
publisher sent me the nth edition of a 
calculus textbook; I resisted reading it). 

The Bookworm’s Top Ten for 1998 (not 
ranked in order) 

1. Donald A. Knuth, The Art of Computer 
Programming, Yo\s. 1, 2, 3. (Addison 
Wesley Longman) 

2. P. Ferguson 8< G. Huston, Quality of 
Service (Wiley) 

3. Berry Kercheval, TCP/IP over ATM 
(Prentice-Hall) 


4. Richard Stevens, UNIX Network 
Programming, vol. 2 (Prentice-Hall) 

5. Ralph Griswold, et al., Graphics 
Programming in Icon (Peer-to-Peer) 

6. B. Schneier & D. Banisar, eds.. 
Electronic Privacy Papers (Wiley) 

7. Bassam Halabi, Internet Routing 
Architectures (New Riders) 

8. Charles Perkins, Mobile IP (Addison 
Wesley Longman) 

9. V. Brown & C. Nandor, McPerl (Prime 
Time Freeware) 

10. John Blair, Samba (SSC) 

And two further notes: for real program¬ 
mers, I think that Harrison & McLennan, 
Effective Tcl/Tk Programming (Addison 
Wesley Longman) and Johnson 8c Troan, 
Linux Application Development (Addison 
Wesley Longman) are truly outstanding; 
and (in self-interest) you might want to 
look at the four volumes of P.H. Salus, 
ed.. Handbook of Programming Languages 
(Macmillan). 

The ASCII Corporation has published 
a Japanese translation of Lions’ 
Commentary and Code. I am told that 
Shinichi Iwamoto has done a superb, 
painstaking job in the translation. 

Happy Holidays! 


Don Bolinger and Tan Bronson 

Applying RCS and SCCS 

O’Reilly & Associates. 1995. ISBN 1-56592-117-8. 
Pp. 501. $29.95. 

Reviewed by Nick Christenson 

<npc@jetcafe.org> 

Some of the most powerful tools avail¬ 
able to an information systems profes¬ 
sional are the version control systems. 
These software packages are designed to 
help track changes made to line-oriented 
text documents. Although most com¬ 
monly used by teams of programmers to 
manage source code, these systems are 
useful for far more than just this one 
application. Unfortunately, version con¬ 


trol systems are also some of the most 
underutilized tools available to IS folks. 
Applying RCS and SCCS describes how 
one can productively use two of the most 
popular of these tools. The availability of 
this information should help encourage 
the tools and methods this book 
describes. 

The book starts out by describing source 
and project control, and throughout it 
explains many of the fundamental con¬ 
cepts of configuration management that 
are necessary for proper maintenance of 
software development projects. There’s a 
lot more to be said about configuration 
management than is printed here. 
However, there are many good books on 
this subject, so the authors should be 
commended for not taking up the read¬ 
er’s attention with an incomplete effort. 

For each concept, the authors explain the 
general theory behind what they are try¬ 
ing to communicate and then elaborate 
on how this is implemented separately 
using the two most popular and widely 
available version control systems: RCS, 
the Revision Control System, and SCCS, 
the Source Code Control System. Because 
of this, the structure of the book flows 
naturally, and readers do not have to 
spend time studying the syntax of a sys¬ 
tem they don’t use. Further, even some¬ 
one who doesn’t use either system can 
efficiently extract considerable informa¬ 
tion of value from this book. This multi¬ 
track writing approach doesn’t always 
work so well, but the authors do a cred¬ 
itable job of pulling it off here. 

The subject of the book is fairly narrow, 
but frankly, I wish more authors would 
narrow the focus of their work so that 
they can write with more detail and pro¬ 
vide real-world examples to the reader. 
Because focus. Applying RCS and SCCS 
provides a great deal of specific, good 
advice and concrete examples that would 
have had to be omitted in a broader 
work. 

Once the issues in using RCS and SCCS 
have been dealt with, the authors turn 
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toward the topic of extending these sys¬ 
tems. To do this, they introduce their 
own extension of these tools, which they 
call TCCS. Although this illustrates their 
concepts well, they might have been bet¬ 
ter off using an existing, widely used if 
less theoretically applicable, extension, 
like CVS. 1 doubt this book will persuade 
many people to adopt TCCS as is, so this 
section probably isn’t as valuable to the 
books potential audience as is the rest of 
it. However, this section can easily be 
skimmed. 

The only other items that may be consid¬ 
ered flaws in this book are that the lack 
of discussion on nonprogramming appli¬ 
cations for version control systems, and 
of a detachable quick reference card. The 
first is not a big deal, because large soft¬ 
ware projects are by far the most com¬ 
plex version control environment one is 
likely to encounter, and it s not too hard 
for system administrators and document 
writers to figure out how to use these 
tools to manage their less complex envi¬ 
ronments from the information given. As 
to the second issue, O’Reilly books have 
recently come with quick reference cards 
that are of questionable utility. I would 
actually find cards that summarized the 
command options for RCS and SCCS 
useful, so I’m a bit surprised that they 
weren’t included. 

The book is well written, and the materi¬ 
al is well worth the time it takes to 
understand it. Version control tools are 
extremely powerful and useful, and every 
information systems professional should 
be intimately familiar with them. It’s my 
opinion that everyone who uses RCS or 
SCCS, could benefit from this book, and 
anyone who does not currently use a ver¬ 
sion control system should read this 
book and begin using one of these tools 
immediately. Further, any programmer 
who uses version control, even if it’s not 
one of the tools covered by this book, 
would be well served to look over the 
general sections on version control issues 
and project management in general. 


Applying RCS and SCCS is a solid book 
on important tools available to the infor¬ 
mation systems professional. The struc¬ 
ture of the book permits efficient learn¬ 
ing of those concepts that are most valu¬ 
able to the specific reader while provid¬ 
ing a narrow enough focus and sufficient 
depth to impart a solid understanding of 
the theory and practice of document 
control. If there is a chance that the topic 
of the book might seem useful, it will 
almost certainly be well worth reading. I 
give this topic my strongest recommen¬ 
dation, and this book does not let us 
down. 

Martin Freiss 

Protecting networks with SATAN 

O’Reilly & Associates, 1998. ISBN: 1-56592-425-8. 
Pp. 112.519.95. 

Reviewed by Nick Christenson 

<npc@jetcafe.org> 

In 1995, the computer security tool 
known as SATAN was released, prompt¬ 
ing numerous articles in the popular 
press predicting that it would touch off 
an avalanche of security break-ins that 
would devastate the Internet. Of course, 
as the authors predicted, this catastrophe 
never occurred, and SATAN took its 
place as a very useful tool for discovering 
security vulnerabilities in one’s network. 
In 1997, Martin Freiss wrote Protecting 
Networks with SATAN as a guide to using 
this powerful software tool. It was origi¬ 
nally published in German and now has 
been translated into English by Robert 
Bach. 

The book begins with a brief description 
of network security and then describes 
how to obtain, build, and install SATAN. 
Next, Freiss provides information on how 
to conduct network scans with SATAN 
and describes what SATAN can test for 
and how it works. The book also pro¬ 
vides information on writing one’s own 
SATAN modules, suggested SATAN 
countermeasures, and concludes with 
some general security advice in a chapter 
entitled “Beyond SATAN.” 


The writing isn’t top flight, but the expla¬ 
nations are clear and the prose is no 
worse than I’d expect from a competently 
translated text. The information it pro¬ 
vides appears correct to me, although I 
found the sections on general network 
security to be pretty sparse. Since they’re 
only provided as background and the 
reader is referred to excellent sources in 
the bibliography, this isn’t a problem. 

The book is short, but this is no disgrace. 
The author has chosen a narrow topic to 
focus on, has explained it with sufficient 
clarity, and has wisely elected not to 
waste the reader’s time with filler materi¬ 
al. I applaud the brevity of the book and 
wish that more technical authors would 
consider writing this efficiently. 

It seems to me that the main reasons why 
the press felt that SATAN’s release could 
result in such widespread chaos were its 
ease of use and familiar Web interface. In 
my opinion, the most remarkable quali¬ 
ties of this software package are its 
intriguing inference engine, which infers 
connections between vulnerable comput¬ 
ers, and its easy extendibility. While the 
book does a nice job of explaining these 
features, SATAN’s user-friendliness 
makes one wonder if the book is really 
necessary at all. I really didn’t find much 
substantive information here that isn’t 
immediately available in the SATAN doc¬ 
umentation. What I did find new was in 
the chapters on detecting and repelling 
SATAN attacks and extending and adapt¬ 
ing SATAN. However, this isn’t quite 
enough to make me able to recommend 
this book. 

I suppose if one is having problems fig¬ 
uring out the documentation, or expects 
to have some difficulty in writing a 
SATAN extension, the book would prove 
useful. Further, at a price less than $20, 
it’s not an extravagant expense, but if one 
is already successfully using SATAN, I 
really don’t expect that this book would 
be all that necessary or even terribly 
helpful, as the SATAN documentation 
does a pretty good job of covering the 
same ground. 
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USEN/X news 


USENIX 

Member Benefits 

As a member of the USENIX Association, you receive 
the following benefits: 

Free subscription to ;login:, 

the Association’s magazine, published six to eight 
times a year, featuring technical articles, system 
administration tips and techniques, practical 
columns on Perl, Java, and operating systems, book 
and software reviews, summaries of sessions at 
USENIX conferences, and reports on various stan¬ 
dards activities. 

Access to papers - 

from the USENIX Conferences starting with 1993, 
via the USENIX Online Library on the World Wide 
Web <http://www.usenix.org>. 

Discounts on registration fees J 

for all USENIX Conferences, as many as ten every 
year. 

Discounts 

on the purchase of proceedings and CD-ROMS from 
USENIX conferences 

PGP Key Signing service 

available at conferences. 

Discounts 

10% off BSDI, Inc. products. 

<www.bsdi.com>. 

Discounts 

10% off Prime Time Freeware publications and 
software <www.pff.com> 

Discounts 

20% off Prentice-Hall books <www.bookpool.com> 
20% off O’Reilly & Associates publications 
<www.ora.com> 

10% off Morgan Kaufmann books (give code :AL0G) 
<www.mkp.com> 

Savings 

10%-20% savings on selected titles from McGraw- 
Hill <www.books.mcgraw-hill.com>, John Wiley & 
Sons <www.wiley.com/compbooks>. The Open 
Group <www.opengroup.org>, and the MIT Press 
(give code UNIXl) <mitpress.mit.edu> 

Special subscription rotes 

15% off The Linux Journal <vmN.ssc.com> 

$5 off The PerIJournal 

<orwant.www.medla.mit.edu/the_perlJournal> 

The right to vote ^ 

on matters affecting the Association, its bylaws, 
election of its directors and officers 

Optional membership 7 ^ 

in SAGE, the System Administrators Guild 

For information regarding membership or benefits, 
please contact 
<office@usenix. org> 

Phone: 510 528 8649 


USENIX International 
Progranns 

International Speakers Program 

The USENIX Association has recently inau¬ 
gurated an International Speakers Program. 
We will assist sister organizations and our 
affiliate member societies in locating and 
sending speakers to conferences worldwide. 
USENIX speakers have presented papers at 
our conferences on such topics as operating 
systems, network security, system adminis¬ 
tration, and languages. USENIX will 

■ assist your organization in ascertaining 
appropriate topics and speakers, 

■ extend invitations, 

■ if needed, fund transportation and 
expenses. 

We only require that the presentation be 
promoted as a “USENIX Presentation.” 
Please contact the Association's Executive 
Director, Ellie Young at <ellie@usenix.org>. 

Your proposal should contain the following 
information: 

■ Wlio is the sponsor of the event? 

■ Contact information (phone, postal and 
email addresses, URL for the organiza¬ 
tion and the event). 

■ A brief description of the event (or of a 
previous similar event). 

■ Topic(s) for which you seek a speaker or 
name(s) of specific speaker(s) you would 
like to invite. 

■ Dates, and the time period the speaker 
will need to be present at the event. 

■ How much support you require from 
USENIX, if any. 

International Affiliate Program 

The Europen.SE <http:www//europen.se> (the 
Swedish National Group of EurOpen), with 
300 members, is the first group to become a 
USENIX Affiliate Member. All members of 
EurOpen.SE enjoy all USENIX individual 
member benefits, except voting privileges. 
All members of an Affiliate group share a 


common expiration date, and a single pay¬ 
ment for renewal be made each year. There 
are many different models for affiliate 
membership. Please contact the 
Association s Executive Director, Ellie 
Young <ellie@usenix.org>. 

Co-Sponsorship of Conferences 

USENIX has agreements with similiar tech¬ 
nical groups to co-sponsor events. These 
arrangements vary depending on the needs 
of each organization, but typically involve 
USENIX assisting with planning, promo¬ 
tion, proceedings, and/or logistics. USENIX 
is currently co-sponsoring the following 
events: 

■ The 1st International System 
Administration and Networking 
Conference (SANE ’98), November 18- 
20, 1998, in Maastricht, The Netherlands, 
with NLUUG and Stichting NLnet. 
<http://www.nluug.nl/events/sane98/>. 

■ NordU99 - 1st Nordic EurOpen/USENIX 
Conference in Stockholm, Sweden. Feb 9- 
12, 1999. <http://www.europen.se/NordU99/> 

■ The 2nd IEEE Workshop on Mobile 
Computing Systems and Applications 
<http://www.research.att.com/conf/wmcsa99/>. 

■ The Fifth Annual International 
Conference on Mobile Computing and 
Networking 

<http://www.acm.org/sigmobile/conf>. 

■ Agent Systems & Programming 
Conference (to be held in May, 1999). 

Inquiries about co-sponsorship should be 
sent via email to Ellie Young 
<ellle@usenix.org>. 


88 


Vol. 23, No. 6 ;login: 






by Peter H. Salus 



Peter H. Salus is the author of ^ Quarter Century of UNIX 
(1994) and Casting the /VeMl995). He has known Lou 
Katz for over 40 years. 


<peter@pedant.com> 


Twenty Years Ago 
in USENIX 


Note the change in title! ;login: (aka 
UNIX NEWS) did not reappear until 
1980. In 1999 Til talk about the 
Association and its activities. 


The January 1979 meeting was to be held 
in Santa Monica, CA. Nearly a year earli¬ 
er, Peter Weiner at Interactive Systems 
asked one of his staff if she could handle 
the arrangements. She did. And she has 
coordinated every USENIX conference, 
symposium, and workshop since. 

That s right. 25-27 January was Judy 
DesHarnais s debut as czarina of the 
meetings. Steve Holmgren chaired the 
meeting. There were about 350 in atten¬ 
dance. (Little did Judy realize that a 
decade later there would be ten times as 
many attendees at the San Francisco 
Hilton.) 


The Association was growing, as was the 
use of UNIX. The end of 1978 saw an 
“installed” board of directors, the appear¬ 
ance of Version 7, the first BSD tape 
(containing Pascal and “the ex editor”), 
the Ritchie-Johnson port to the Interdata 
8, the Wollongong port to the Interdata 7, 
the port to 32V by Charlie Roberts and a 
group at Holmdel, the publication of 
uucp, and the first meeting of the 
NLUUG - and, of course, the publication 
of The C Programming Language and the 
“blue” BSTJ. 

It was quite a year. 

Judy, my personal thanks for all those 
conferences, workshops, board meetings, 
and symposia. 


Statement of Ownership, Management, and Circulation, 10/1/98 

Title: :login:.Pub. No. 1044-6397. Frequency: Bimonthly. Seven issues published annually. Subscription price $50 individuals and 
institutions. Office of publication: USENIX Association, 2560 9th Street, Suite 215, Berkeley, Alameda County, CA 94710. 
Headquarters of Publication: Same. Publisher: USENIX Association, 2560 9th Street, Suite 215, Berkeley, CA 94710. Editor: Rob 
Kolstad. Managing Editor: Jane-Ellen Long, both located at office of publication. Owner: USENIX Association. The purpose, function, 
and nonprofit status of this organization and the exempt status for Federal income tax purposes has not changed during the preced¬ 
ing 12 months. 

Extent and nature of circulation Average no. of copies of each issue in Actual no. of copies of single 

preceding 12 months issue published nearest to filing 


A. Total no. of copies 

B. Paid and/or Requested Circulation 

10,117 

10,920 

Sales through Dealers 

0 

0 

Mail Subscribers 

9,439 

10,315 

C. Total Paid and/or Requested Circulation 

9,439 

10,315 

D. Free Distribution by Mail 

100 

135 

E. Free Distribution Outside the Mail 

408 

350 

F. Total Free Distribution 

508 

485 

G. Total Distribution 

9,947 

10,800 

H. Copies Not Distributed 

170 

120 

1. Total 

10,117 

10.920 

Percent Paid and/or Requested Circulation 

95% 

96% 


I certify that the statements made by me above are correct and complete. 
Ellie Young, Executive Director 


by Rob Kolstad 

Rob Kolstad is head coach of the USA Computer Olympiad 
Team 


<kolstad@busenix.org> 


USA Bags Gold at 101 

Four representatives of the USA 
Computing Olympiad attended the world 
championships in Setubal, Portugal on 
September 4-11, 1998. The International 
Olympiad on Informatics (lOI) hosted 
over 250 competitors from over 65 coun¬ 
tries. 


Adrian Sox, winner of almost every USA 
contest this year, earned a gold medal in 
the competition. Adrian is now a fresh¬ 
man at Carnegie Mellon University. 

Matt Craighead, 16-year-old USACO 
wunderkind, won a silver medal in a con¬ 
test marred by judging irregularities. 

Matt is now a freshman at MIT, having 
closed out his USACO career with the 
best record of any USA participant ever. 

The 1998-1999 season is under way, with 
four contests scheduled before the sum¬ 
mer training camp, and a trip to Turkey 
next fall. Please refer interested students 
to <www.usaco.org> for information on 
joining the mailing list and participating 
in the contests. 
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3rd Symposium on Operating Systems Design and Impfementation 

OSDI '99 


Monday-Thursday, February 22-25, 1999 • New Orleans, Louisiana 


Tutorial Program Monday, February 22, 1999 

3 tutorials covering: 

Building Security (for Developers), Marcus J. Ranum, Network Flight Recorder 
Windows NT Internals, Jamie Hanrahan, Kernel Mode Systems 

Deploying and Benchmarking Web Caches, Peter Danzig, Network Appliance and USQ Alex Rousskov, National Laboratory for Applied 

Network Research (NLANR) 

Register now to guarantee your first choice—seating is limited. 

Tochnical Sossions Tuesday-Thursday, February 23-25, 1999 

_ Tuesday, February 23, 1999 _ 

Opening Remarks and Keynote Address: 

The Blind Men and The Elephant 

Jim Gettys, Compaq Computer Corporation 

H We are the blind men examining the Web elephant. The Interactions between bandwidth, latency, network transport protocols, access protocols, 
interfaces, and content of the Web are not commonly understood. I will describe my view of the elephant 

"And so these men of Indostan, disputed loud and long, each in his own opinion, exceeding stiff and strong. Though each was partly in the right and 
all were in the wrong! So, oft in theologic wars, the disputants, I ween, tread on in utter ignorance, of what each other mean, and prate about the 
elephant not one of them has seenl" — John Godfrey Saxe 

Jim Gettys is a Senior Consultant Engineer for Compaq Computer Corporation's Industry Standards and Consortia Group and is a Visiting Scientist at 
the WSC at Ml T Jim is the chair of the HTTP/NG Protocol Design Working Group (PDGj of W3C. Jim is the editor of the IETF "Hypertext Transport Protocol— 
HTTP/U" document 

With Bob Scheifler, Jim is co-designer of the X Window System. Gettys' designed the X Library and contributed to X Window System core protocol. Via the Internet 
Gettys coordinated the efforts of contributors both inside and outside Digital to the development ofX Windows System, one of the first major software systems to be 
built in a distributed, collaborative fashion. 

I/O 

Session Chair: Sean O'Malley, Network Appliance 

Automatic I/O Hint Generation through Speculative Execution 
Fay Chang, Garth A. Gibson, Carnegie Mellon University 

lO-Lite: A Unified I/O Buffering and Caching System 

Vivek S. Pai, Peter Druschel, Willy Zwaenepoel, Rice University 

Virtual Log Based File Systems for a Programmable Disk 

Randolph Y. Wang, University of California, Berkeley. Thomas E. Anderson, University of Washington: David A. Patterson, University of California, Berkeley 

Resource Management 

Session Chair: Greg Minshall, Siara Systems 

Resource Containers: A New Facility for Resource Management in Server Systems 

Gaurav Banga, Peter Druschel, Rice University, Jeffrey C. Mogul, Western Research Laboratory, Compaq Computer Corporation 
Defending Against Denial of Service Attacks in Scout 

Oliver Spatscheck, University of Arizona; lerry L Peterson, Princeton University 

Self-Paging In the Nemesis Operating System 

Steven Hand, University of Cambridge Computer Laboratory 

Panel Discussion: VM-based Operating Systems 

Moderator: Paul Leach, Microsoft Corporation 

Participants: TBD 


Visit our web site; http://www.tisenix.org/events/osdi99 





3rd Symposium on Operating Systems Design and Implementation 

OSDI '99 


Monday-Thursday, February 22-25, 1999 • New Orleans, Louisiana 


_ Wednesday, February 24, 1999 _ 

Kernels 

Session Chair: Rob Pike, Lucent Technologies 

Tornado: Maximizing Locality and Concurrency in a Shared Memory Multiprocessor Operating System 

Michael Stumm, Ben Gamsa, Jonathan Appavoo, University of Torontcr, Orran Krieger, IBM TJ Watson Research Center 

Interface and Execution Models In the Fluke Kernel 

Bryan Ford, Mike Hibler, Jay Lepreau, Roland McGrath, Patrick Tullmann, University of Utah 

Rne-Grained Dynamic Instrumentation of Commodity Operating System Kernels 
Barton P. Miller, Ariel Tamches, University of Wisconsin 

Real-Time 

Session Chair: Mike Jones, Microsoft Corporation 

ETI Resource Distributor: Guaranteed Resource Allocation and Scheduling in Multimedia Systems 
Miche Baker-Harvey, Equator Technologies, Inc. 

A Feedback-Driven Proportion Allocator for Real-Rate Scheduling 

David C. Steere, Ashvin Goel, Joshua Gruenberg, Dylan McNamee, Calton Pu, and Jonathan Walpole, Oregon Graduate Institute 

A Comparison of Windows Driver Model Latency Performance on Windows NT 4.0 and Windows 98 
Erik Cota-Robles, James R Held, Intel Corporation 

Distributed Systems 

Session Chair: Tom Anderson, University of Washington 

Practical Byzantine Fault Tolerance 

Miguel Castro, Barbara Liskov, MIT Laboratory for Computer Science 
The Coign Automatic Distributed Partitioning System 

Galen C. Hunt, Michael L. Scott, Microsoft Research; Michael L. Scott, University of Rochester 

Works-in-Progress 

Moderator: John Hartman, University of Arizona 

_ Thursday, February 25, 1999 _ 

Virtual Memory 

Session Chair; Kai Li, Princeton University 

Tapeworm: High-Level Abstractions of Shared Accesses 
Peter Keleher, University of Maryland 

MultiView and Mlllipage - Fine-Grain Sharing in Page-Based DSMs 
Ayal Itzkovitz, Assaf Schuster, Technion—Israel Institute of Technology 

Optimizing the Idle Task and Other MMU Tricks 

Cort Dougan, Victor Yodaiken, New Mexico Institute of Technology; Paul Mackerras, Australian National University 

Filesystems 

Session Chair: Bruce Lindsay, IBMAImaden Research Center 

Logical vs. Physical RIe System Backup 

Norman C. Hutchinson, Stephen Manley, Michael Federwisch, Guy Harris, Dave Hitz, Steven Klelman, and Sean O'Malley, Network Appliance 
The Design of a Multicast-Based Distributed File System 

Bjorn Gronvall, Assar Westerlund, and Stephen Pink, Swedish Institute of Computer Science 

Integrating Content-Based Access Mechanisms with Hierarchical File Systems 
Udi Manber, University of Arizona; Burra Gopal, Microsoft Corporation 
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Announcement and Call for Papers 

MobiCom '99 

The riRh Annual international Conference on 
Mobile Computing and Networking 

August 15 -19,1999 Seattle, Washington, USA 

http://www.acm.org/sigmobile/conf 

Sponsored by ACM SIGMOBILE 

Technically Co-sponsored by the IEEE Communications Society 
In cooperation with ACM SIGCOMM, SIGOPS, SIGMETRICS, and SIGMOD; 
the USENIX Association; the lEICE; and the lEE 



PAPERS: Technical papers describing previously unpublished, original, completed research, not currently under review by 
another conference, journal, are solicited on the following topics: 

• Applications and computing services supporting mobile users • Mobile agents 

• Network architectures, protocols or service algorithms to cope • Push and pull data dissemination systems 

with mobility, limited bandwidth, or intermittent connectivity • Power management 

• Database and data management issues in mobile computing • Wireless multimedia systems 

• Design and analysis of algorithms for mobile environments • Satellite communication 

• Security, scalability and reliability for mobile/wireless systems • Location-dependent applications 

• Performance of mobile/wireless networks and systems • Distributed system aspects of mobile systems 

• Integration and interworking of wired and wireless networks • Adaptive applications interfaces for mobile systems 

• Influence of lower layers on the design and performance of • Architectures of mobile/wireless networks and systems 

higher layers • Traffic integration for mobile applications 

• Mobile network protocols 

All papers will be refereed by the program committee. Accepted papers will be published in the conference proceedings. Papers of 
particular merit will be selected for publication in the ACM/Baltzer journals Wireless Networks (WINET) and Mobile Networks and 
Applications (MONET). 

(NEW!) SPECIAL PAPERS FOR THE MOBICOM “NEXT CENTURY CHALLENGES” SESSION: MobiCom 
solicits short papers (8 pages max.) that challenge the mobile computing community with new technologies or visionary applications. 
Such papers should provide stimulating ideas or visions that may open up exciting avenues of mobile computing research. Papers will 
be reviewed and should be submitted as regular MobiCom submissions (although they do not have to be as technical as regular 
submissions). However, the cover letter that accompanies the submission should be clearly marked for “MobiCom Challenges”. 

HOW TO SUBMIT: All paper submissions will be handled electronically. Authors should E-mail a PostScript version of their 
full paper to tnobicom99@cs.rutgers.edu. This E-mail address will become operational by December 15, 1998. In order to ensure that 
the PostScript versions of the papers can be printed, authors should be careful that their papers meet the following restrictions: 

• PostScript version 2 or later. 

• No longer than 15 pages. 

• Fits properly on US letter size paper (8.5 X 11 inches). 

• Reference only Computer Modem or standard Adobe printer fonts (i.e. Courier, Times, 

Roman, or Helvetica); other fonts may be used but must be included in the PostScript file. 


In addition, authors should separately E-mail the title, author names and full address, and abstract of their paper to the Program 
Chairs, Tomasz Imielinski {imielins@cs.rutgers.edu) and Martha Steenstrup {msteenst@bbn.com). All submitted papers will be 
judged based on their quality through double-blind reviewing, where the identities of the authors are withheld from the reviewers. 
Authors names should not appear in the paper or in the PostScript file. 

TUTORIALS: Proposals for tutorials are solicited. Evaluation of proposals will be based on the expertise and experience of the 
instructors, and on the relevance of the subject matter. Potential instmctors are requested to submit a tutorial proposal of at most 5 
pages, including a biographical sketch, to the Tutorial Co-Chairs, Michele Zorzi {zorzi@cwc.ucsd.edu) and Krishna Sivalingam 
{krishna@eecs.wsu.edu) by Jiinuary 15, 1999. 

PANELS: Panels are solicited that examine innovative, controversial, or otherwise provocative issues of interest. Panel proposals 
should not exceed 3 pages, including biographical sketches of the panelists. Potential panel organizers should contact the Panels 
Chair, Roy Want {want@parc.xerox.com). 

STUDENT PARTICIPATION: Papers with a student as a primary author will be considered for a cash award of US$500 for 
the best student paper competition. Student authors should clearly indicate with their submission that they would like to be considered 
for this award. 

IMPORTANT DATES: Submissions due: January 15,1999 

Notification of acceptance: April 5,1999 

Camera-ready version due: May 15,1999 

FOR MORE INFORMATION: Please contact the Program Co-Chairs: Tomasz Imielinski, imielins@cs.rutgers.edu, Tel: -i-l 
732 445-3546, Fax: -i-l 732 445-1003; or Martha Steenstrup, msteenst@bbn.com, Tel: -i-l 617 873-3912, Fax: +\ 617 873-6091; or 
the Local Chair, Randy Granovetter, randygr@microsoft.com, Tel: +1 425 703-7446, Fax: + 1 425 936-7329. This Call for Papers, 
as well as other MobiCom'99 information, is available on the Web on the ACM SIGMOBILE Home Page at 
http ./Avww.acnu org/sigmobi le/ 























At Sprint Paranet, we take a few 
things seriously: Technology. Success. 
Career Development. That's how we've become a 
leading provider of distributed network management solutions 
for the Fortune 1000. We'll give you a chance to push the limits, and 
be rewarded. You'll see your biggest ideas put to use. And since we're 
vendor-independent, you'll work with a host of technologies. Sound like fun? 
Then explore the following positions, and watch your ideas — and your career — 
really take off. 


Sr. UNIX Systems Analyst 


Position requires 5-10 years' experience administering medium to large 
environments on multi-platforms (Solaris, HP-UX, and AIX). Must have expert 
networking knowledge of DNS, NFS, NIS (+), Automounter and TCP/IP. 
Strong shell scripting development skills (C, C++, Perl, AWK, Bourne, 
Korn) is a plus. UNIX Security and Disaster Recovery projects 
experience desired. 


UNIX Systems Analyst 

Must have experience administering medium to large 
environments on multi-platforms including Solaris, HP-UX, AIX, 
NFS, NIS+, DNS, Automounter, TCP/IP and multi-platform 
integration. 

Ready to join Sprint Paranet? Then bring your best ideas 
with you. Because in addition to an excellent 
compensation package, we provide an open, innovative 
environment where creativity flourishes. For 
consideration, please forward your resume to: Sprint 
Paranet, Job Code LOGIN1299; Fax (888) 
525-7476; Email: eagles-login@sprint- 
paranet.com (text format is strongly 
preferred). Please indicate geographic 
preference. EOE, m/f/d/v 


www.sprintparanet.conn 
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MORGAN KAUFMANN PUBLISHERS 


Got Questions? We have Answers! 
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BeOS 


Practical File System Design 
with the Be File System 
By Dominic Giampaolo 
November 1998; 256 pages; paper; 
ISBN 1-55860-497-9; S.^4.95 


BeOS 

Porting Unix Applications 
By Martin C. Brown 
August 1998; 496 pages; paper; 
ISBN 1-55860-532-0; $44.95 
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UML for N'isual Basic 6.0 Developers 
Using N'isual .Modeler and 
Rational Rose 98 
By Paul Harmon & Brian Sawyer 
No\ ember 1998; 400 pages; paper. 

ISBN 1-55860-545-2; $39.95 


Jasmine 

Obfect 

Database 


% Ualiimr«fia 
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I he Jasmine Object Database 
.Multimedia .Applications for the Web 

By Setrag Khoshafian. Surapol Dasananda 
& Norayr .Minassian 
August 1998; 432 pages; paper; 
ISBN 1-55860-494-4; $49.95 



Web Farming 
for the Data Warehouse 
By Richard llackathom 
No\ ember 1998; 384 pages; paper; 
ISBN l-558W)-503-7; $44.95 
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Also Forthcoming: 


Unix Networking 
Clearly Explained 
By Richard L. Petersen 
l ebmary’ 1999; 500 pages; paper; 
ISBN 0-12-552145-6; $39.95 


I 


I'he Grid 

Blueprint for a New 
C'omputing Infrastructure 
l-dited by Ian Foster & Carl Kesselman 
July 1998; 701 pages; cloth; 

ISBN 1-55860-475-8; $62.95 


Order from Morgan Kaufmann Publishers 1 1 

Mail: Harcoiirt Brace ^ Co., Altn. Order Fulfillment Dept., Q 

6277 Sea Harlx^ir Drive, Orlando, FL 32887, 

Phone: US/ Qinada 800-745-7323, 407-345-3800 (Inil.) 

^ . Pleasementioi 

Fax: 800-874-6418,407-345-1060 (Inti.). 

Email: orders(amkp.com Web: www.mkp.com Also available at vour local bookstores! 


10% Discount 
V^toUsenix Members!^ 

Please mention code 49214 when ordering. 

































































TECHNOLOGY 
AND PRIVACY 

The New Landscape 

edited by Philip E. Agre 
and Marc Rotenberg 
“Commerce, bandwidth, equity of access, 
copyright—these are some of the battles that are 
taking place in the Internet environment, but the one 
that will affect all of us is the battle over privacy. 
Technology and Privacy is an excellent survey of the 
different issues on the different fronts. This is 
important reading for journalists, legislators, 
activists, and citizens.” — Steve Cisler, 

Advanced Technology Group, Apple Computer 
“[These essays are) brilliant and clearly written. They 
offer the most innovative thinking about this issue in 
a decade and a half. Agre truly moves the privacy 
debate ahead...a significant new contribution to the 
privacy debate, even among professionals who deal 
with these issues regularly.” — Robert Ellis Smith, 
Publisher, Privacy Journal 
280 pp., 13 illus. $15 paper 

original in paperback 

COORDINATING 
THE INTERNET 

edited by Brian Kahin and James H. Keller 
Once entirely built and supported by the U.S. 
Government, the Internet is now remarkably 
decentralized and uninstitutionalized. Its future is 
not tied to any particular organization, but as It 
grows in scope, bandwidth, functionality, and 
“internationality,” it will require greater coordination. 
At the moment It is not clear what kind of coordinat¬ 
ing mechanisms and institutions will evolve. 

Problems discussed in this book include network 
address allocation and the management of domain 
names, intellectual property, and finances. 

Solutions explored range from bilateral and universal 
agreements between nations to consensual 
standards negotiated in the open market. 

A publication of the Harvard Information 
Infrastructure Project 
500 pp. $25 paper 


iWarp 


Anatomy of a Parallel 
Computing System 

Thomas Gross and David R. O'Hallaron 
“There is no doubt that iWarp was an important 
research effort. This work is significant as an 
archival record of the innovative research under¬ 
taken In the iWarp project.” —Siddhartha Chatterjee, 
University of North Carolina at Chapel Hill 
The IWarp is an experimental parallel system 
designed and built Jointly by Carnegie Mellon 
University and Intel Corporation. This book 
describes the complete iWarp system, from 
instruction-level parallelism to final parallel 
application. The authors present a range of issues 
that must be considered to get a real system into 
practice, and also provide a start-to-finish history of 
the project. Including what was done right and what 
was done wrong. 

530 pp., 270 illus. $45 


USENIX members receive a 15% discount 
on the following MIT Press publications: 


PRIVACY ON 
THE LINE 

The Politics of Wiretapping 
and Encryption 

Whitfield Diffie and Susan Landau 
“A remarkable blend of technical expertise, historical 
analysis, and provocative policy argument. This is an 
indispensable book for anyone hoping to get to the bottom 
of the disputes over cryptography, computer security, privacy, 
and wiretapping that currently divide the law enforcement, 
civil liberties, and high tech communities.” 

— Kenneth W. Dam, University of Chicago 
352 pp. $25 

SOFTWARE 



AGENTS 


edited by Jeffrey M. Bradshaw 
A comprehensive survey of the state of the art in the design 
and use of intelligent software agents and in the creation of 
communication ability between agents. The book presents the 
views of proponents and critics of software agents, describes 
how agents are used to enhance learning and provide 
intelligent assistance to users in situations where traditional 
direct manipulation interfaces alone are insufficient, and 
discusses agent-to-agent communication and the use of 
agents to provide intelligent interoperability in distributed 
systems and the Internet. 

450 pp. $42 paper 

THE EVOLUTION 


OF C++ 


Language Design in the 
Marketplace of Ideas 

edited by Jim Waldo 

This collection of articles traces the history of C-n- from its 
infancy in the Santa Fe workshop, to its proliferation today as 
the most popular object-ortiented language for microcomput¬ 
ers. Waldo notes In his postscript that In the process of 
evolving, the language has lost a clearly articulted, generally 
accepted design center, with no common agreement about 
what it should or should not do in the future. 

279 pp. $30 paper 

now in paperback 

INTERNET 


DREAMS 


Archetypes, Myths, and Metaphors 

Mark Stefik 

“Clever Juxtapositloning of essays wrapped In the author's 
Insightful commentary paints a telling picture: the Internet is 
unique, yet the policies that shape its design and use are 
often influenced by the metaphors that we ascribe to 
\X...Internet Dreams Is not Just a philosophical argument, but a 
valuable history (and prehistory) of the Net. In fact, no other 
book that I'm aware of portrays the philosophical development 
of the Internet with such depth and perspective.”— Byte 
440 pp., 24 illus. $15 paper 



_The MIT Press • Rve Cambridge Center • Cambridge, MA 02142-1399 USA 


To order by phone, call 800-356-0343 (US & Canada) or (617) 625-8569. 

E-mail orders: mitpress-orders@mit.edu • The operator will need this code: UNiXl 



http://mitpress.mit.edu 
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by Rob Kolstad 

Rob Kolstad is a long-time 
USENIX member, having 
served as chair of several 
conferences and workshops, 
director on the Board, and 
editor of ;login:. He is also 
head coach of the USA 
programming team. 
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Reading 

Do you read a lot? Ever stop to count it up? I can’t believe how many written words 
pass before my eyes. 

First of all, there’s email. A dozen or two notes here, a dozen or two there - every day - 
and it adds up. I like little tiny notes, e.g., “please unify field theory; urgent, due at 
2:00.” I hate those long rambling ones where you hear about the weather and the new 
nieces and nephews. You never quite know what the action item is. In the worst case, 
you’re expected to remember the names and birth dates of the new nieces and nephews 
the next time you see that email writer. 

My email includes a few digests and summaries. I get a daily 10,000 word summary of 
news in the computer industry. That’s a lot of words! I also get Edupage, which I really 
like. It’s short and to the point. 

Maybe you read netnews (USENET). I skim a tiny number of groups, including movie- 
reviews, some free UNIX discussions, risks-digest, and a security group. The groups I 
read are fairly reasonable about signal to noise ratio. Takes 1-5 minutes/day; not that 
many total words to read (I don’t read all the notes). In 1977-1980 I recall reading all of 
netnews every day. I guess those would be “the good old days.” 

Then there’s paper. I get 1-3 periodicals per day (six days per week) in addition to the 
usual letters and solicitations. The load of periodicals is staggering. I used to feel oblig¬ 
ated to read them; that didn’t last long! Now I look at the cover, skim the table of con¬ 
tents, read (or skim) those articles of interest and toss the mag. Sometimes this process 
takes less than 20 seconds. 

Except for EE Times (a weekly of 60-100 pages or so in large tabloid format). I love EE 
Times. They talk about hardware, of course. I don’t know much about hardware, so it’s 
always fascinating for me. I love hearing about the new Silicon-Germanium devices (4x 
faster than silicon with reduced power as well). I love hearing about the new discoveries 
in physics and then seeing them translated into actual devices or products five years 
later. It’s keen. I look at every headline in EE Times . 

I also run some mailing lists (800 members with three notes/week; and two more 
(15,000 and 40,000) of one to two per month. It’s interesting to hear from everyone - 
there’s a very diverse set of styles and needs. 

I also edit newsletters, including this one. Lots of reading there. I edit occasional articles 
for people; books, too. 

I guess it boils down to the idea that I spend most of my day sucking in information 
and then trying to keep it somewhere. The late Dr. Dan Slotnick (University of Illinois 
professor) lamented this particular problem by bemoaning the loss of French verbs as 
he filed more information. It’s worse for me; I never took French! 

Nevertheless, it’s neat to read and process so much information and even share it occa¬ 
sionally. There are so many sources of fairly good data and information that I’m start¬ 
ing to believe that there might even be a bright future for this Internet thing. 
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Happy Hacking Keyboard 

The Ultimate Personal Keyboard 


Features: 

Compatible with PC (PS/2), 
Macintosh (ADB), Sun/SPARC 

CTRL key is located where it 
should be 

No "Windows" key 

No designated Function keys 
(can be generated with "Fn" key) 

A compact, custom styled, 
hackers dream come true 


Let us make your key¬ 
board dreams come true! 
Come see us at USENIX 
Lisa'98 Exhibition in 
Boston, MA. 

Try one for yourself in 
the terminal room or at 
our booth-71. 

A special show surprise 
will be given to the first 
150 customers. 

If you can't wait to 
know more about the 
keyboard, contact us at 
408-573-7700 or visit 
our web product page. 

httf)://www.pfuca.com/products/hhkb 


AmcriCSj InCi 2099 Gateway Place, suite 75O, San Jose CA, 95110 Tel: 408.573.7700 Fax 408.573.7707 

URLhttp://www.pfuca.com/products/hhkb 
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CONNEa WITH USENIX 


MEMBERSHIP AND PUBLICATIONS 

USENIX Association 
2560 Ninth Street, Suite 215 
Berkeley, CA 94710 
Phone: 510 528 8649 
FAX: 510 548 5738 
Email: <office@usenlx.org> 


WEB SITE 


http://www.usenix.org 


PGP INFORMATION 
All correspondence to: 

1998 Operational Key 

Key ID: 1024/F6F82613 1997/11/21 

USENIX 1998 <pgp@usenix.org> 

Key fingerprint = 80 6F B5 48 C2 lA B8 45 
48 5F F2 38 E6 41 BO 61 


1998 Signing Key 

Key ID: 1024/4F75A901 1997/11/21 
USENIX 1998 Signature 
<http://www.usenix.org/pgp/pgpsig.html> 
Key fingerprint = 05 FD CF A1 2F 47 00 5C 
69 C2 25 E4 66 89 A6 9B 


USENIX master key <not-for-email>; 

Key ID: 1024/2FEA2EF1 1996/04/08 
Key fingerprint = DB A7 50 99 66 E4 8A A9 
80 B2 D9 E2 FE DA 00 5E 
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CONTRIBUTIONS SOLICITED 

You are encouraged to contribute articles, book reviews, 
and announcements to ;login:. Send them via email to 
<login@usenix.org> or through the postal system to the 
Association office. 


Send SAGE material to <tmd@usenix.org>. The 
Association reserves the right to edit submitted material. 
Any reproduction of this magazine in its entirety or in 
part requires the permission of the Association and the 
author(s). 


The closing dates for submissions to the next 
two issues of ;login: are and February 2,1999, and 
April 8,1999. 


ADVERTISING ACCEPTED 

;login: offers an exceptional opportunity to reach 9,000 
leading technical professionals worldwide. 

Contact: Cynthia Deno 

cynthia@usenix.org 
408 335 9445 
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USENIX Association 
2560 Ninth Street, Suite 215 
Berkeley, CA 94710 

POSTMASTER 

Send Address Changes lo ;login: 
2560 Ninth Street, Suite 215 
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